recommended micro sd card ?

[tkaiser]

they should really start rating random i/o speeds imho

This won't happen anytime soon so it's the responsibility of SBC vendors to stop recommending crap like 'choose any class 10 rated SD card' and to inform their users what's really important.

I don't know much about Android and lack the skills to debug Android stuff. But it was absolutely easy to reproduce this behaviour. I tested RemixOS with a 32GB Samsung EVO and with an Intenso 4GB crap card. Difference like day and night since the Intenso showed 30 times lower random I/O performance. With this card RemixOS was not useable and the whole user experience was just 'stuttering all the time'.

And a few months ago when I tested some Armbian Desktop builds for H3 boards (share the same SDIO implementation with Pine64) I was able to debug the dependency on fast random writes. If you open up something like Firefox for example then this app starts constantly writing to the card, uses fsync calls to ensure changes are written to card immediately and this alone blocks nearly all I/O when used with an 'average SD card' (see the Kingston and PNY numbers from this thread and compare with the even cheaper Samsung EVOs that outperform the aforementioned many times). It's explained here: https://wiki.mozilla.org/Performance/Avo...O_Patterns

And if you read this and then test the SD card in question with 32KB record size just to realize that many/most cards show really bad write performance with 16K and 32K then everything is pretty obvious: You have been fooled by irrelevant speed class ratings and your whole 'user experience' sucks simply since the OS is constantly stuck in I/O processes since random writes are way too slow.

[hyperlogos]

If you want to be sure to get a useful test with pine, install Linux to the prospective cards and run the test in Linux on pine.

Thank you for that, hyperlogos; I know that is prudent advice, but I also know that do so far exceeds my capabilities.

It's no harder than installing android, you only have to install one package ("iobench") and run it on your boot device, you can for example run it in /home to get a good result.

---

And a few months ago when I tested some Armbian Desktop builds for H3 boards (share the same SDIO implementation with Pine64) I was able to debug the dependency on fast random writes. If you open up something like Firefox for example then this app starts constantly writing to the card, uses fsync calls to ensure changes are written to card immediately and this alone blocks nearly all I/O when used with an 'average SD card'

Yes, it is common to disable fsync on devices with slow storage. This is done on many roms for the Transformer Prime, for example. I note that I actually get better performance with Linux on an SD card than I do in Android, and I blame it on Android's egregious overuse of fsync. We have a thing called delayed writes for a reason, and that reason is performance. You don't need to fsync several times a second unless your OS is so unstable that you expect it to explode any fraction of a second. But you do need to fsync more than not at all, so disabling it is not a solution either. Android desperately needs some IO scheduling work. I noticed this when downloading a file, too. You should NOT have any trouble downloading a file, because that's a stream, the system is doing little work, and Android should just cache the data until it has enough to be worth writing. That it doesn't is PATHETIC, and Android is exacerbating this problem due to bad design.

[tkaiser]

You should NOT have any trouble downloading a file, because that's a stream, the system is doing little work, and Android should just cache the data until it has enough to be worth writing. That it doesn't is PATHETIC, and Android is exacerbating this problem due to bad design.

True. But please read through the many threads here that claim 'slow download speeds in Android'. I bet most of these are related to 'slow random I/O writes' + 'Android sucks' in reality. And the same is true for some Linux apps (eg. ownCloud) too: A whole thread over 2 pages just to convince a user that his storage media suffers from slow random writes and the only solution is to throw the slow media in the bin and to replace it with something fast enough: http://forum.armbian.com/index.php/topic...etlastpost

Anyway: This is the reason Android devices are normally equipped with NAND or eMMC and the manufacturers take care that random I/O performance of those is high enough. Just to workaround the issues. Therefore combining the Pine64 with Android, RemixOS or a desktop Linux and trying to use any  SD card can't work (or let's better say it ends with the symptoms the forums are full of: whining about stuttering). And until this will not be documented and the real reason outlined (it's all about random I/O -- forget about the silly 'speed class' ratings) nothing will change and we'll see a few daily threads complaining about 'all OS images are stuttering'.

[hyperlogos]

I wonder, actually, if there is a tunable I/O scheduler that could help mitigate this problem for users with crappy uSD cards.

In any case, my Samsung Evo+ 32GB should arrive today via Amazon Prime and then I will move the contents of my Sandisk Ultra 32GB to it, and hopefully party on. Probably I will just use Ti Backup rather than actually transferring the image. Then the Sandisk goes back in my TF201, where it just stores data.

[NondescriptMember]

Therefore combining the Pine64 with Android, RemixOS or a desktop Linux and trying to use any  SD card can't work (or let's better say it ends with the symptoms the forums are full of: whining about stuttering).

I know these questions are now outside the scope of this thread, but they logically progress in thought at this point:

Due to these constraints, if your intent was to build a Kodi streaming box with Ethernet (This was my intent--though I realize that it's likely not yours), what OS would you suggest for the Pine64+?

Relatedly, what type of appliance do you envision would make the Pine64+ most useful?

[tkaiser]

users with crappy uSD cards.

These users don't know that they have crappy cards. They were told to use 'class 10' (irrelevant sequential transfer speeds), then they buy these card somewhere and then they end up with something like this:



This card is 15 times slower than an EVO or EVO+ of the same size. And even 30-40 times slower than eMMC normally used in more recent Android devices. But it also gets even worse. Take the 'Kingston 16GB Micro SDHC Card 90 MB/s UHS-I U3' tested by one of our Armbian users at the end of this thread: http://forum.armbian.com/index.php/topic...rformance/

'90 MB/s UHS-I U3' sounds really fast. But when we're talking about 4K random writes then a cheap EVO is 5 times faster and at 16K it gets really horrible since this Kingston card (like many many other 'bad brand' cards) is then 150 times slower than a cheap EVO. And this is stuff that really matters. That's the stuttering people are constantly reporting.

[hyperlogos]

Well, I already figured out not to buy PNY cards. And I don't expect Kingston to be fast, either. I have a Samsung Evo+ 32GB now.

[NondescriptMember]

Here are my results on the new 64gb Samsung Evo+ card I bought after the PNY fiasco.
   
I ran the CrystalDiskMark test twice: with 50MiB and 16GiB (just for kicks).  I was surprised to see such a difference, but the 50MiB compared to the old PNY card is also a stark contrast.
I just loaded the newest Android image to this new card.  Very stable, but I'm having external issues with my router (constantly resetting).  I was unable to test Internet functionality as a result.

[tkaiser]

I just loaded the newest Android image to this new card.  Very stable

Isn't it funny that using an SD card with ultra slow random writes even leads to Android behaving unstable and that problems are gone when using any recommended SD card that shows high random I/O performance?

And still only bullshit recommendations like 'speed at least class 10' available in Pine64 wiki leading to all sorts of troubles for their users. But why should this change? Why spending a minute on improving documentation when their users can waste hours and hours of their live due to missing/wrong recommendations.

BTW: With the 16GB test something clearly went wrong and you should keep in mind that when the card is used inside Pine64 the board's SDIO implementation limits sequential transfer speeds anyway to 23MB/s max. All the numbers here also apply to Pine64: http://forum.armbian.com/index.php/topic...rformance/

[tllim]

I just loaded the newest Android image to this new card.  Very stable

Isn't it funny that using an SD card with ultra slow random writes even leads to Android behaving unstable and that problems are gone when using any recommended SD card that shows high random I/O performance?

And still only bullshit recommendations like 'speed at least class 10' available in Pine64 wiki leading to all sorts of troubles for their users. But why should this change? Why spending a minute on improving documentation when their users can waste hours and hours of their live due to missing/wrong recommendations.

BTW: With the 16GB test something clearly went wrong and you should keep in mind that when the card is used inside Pine64 the board's SDIO implementation limits sequential transfer speeds anyway to 23MB/s max. All the numbers here also apply to Pine64: http://forum.armbian.com/index.php/topic...rformance/

Thanks on your comments and inputs, I have post on wiki page that on your random R/W factor recommendation. This is a good fact and a lot of people, including myself, overlook.