tkaiser

SD card performance

Recommended Posts

@duyfken

 

Can you retest sandisk card, but this time format the card with ERASE setting in sdformatter. Maybe the card is acting up or something unusual is happening when handling smaller (4k) chunks of data.

 

Also it might make sense to repeat the test a few times, as @tkaiser is continuously suggesting.

Share this post


Link to post
Share on other sites
6 minutes ago, hojnikb said:

I suggest locking the thread then and just updating OP with relevant results/information :P

 

It's only you constantly flooding threads with useless stuff. I finally give up now.

Share this post


Link to post
Share on other sites

@tkaiser

This is a "Free" forum section (even though we don't have any written policies on forum posts in different sections), and IMO instead of locking up random threads we could split this into two: "SD card performance benchmarks" with a strict policy of posting only iozone results and "SD card performance discussion" with whatever else as long as the discussion stays on topic.

 

Reopening the thread back, we can always split/move/delete off-topic posts.

Share this post


Link to post
Share on other sites

A google doc spreadsheet allowing everyone to to add their result (after approved by someone from the mod team) would make this much more readable and easier to maintain. And keeping this thread for discussion only.

tkaiser already did a spreadsheet for some cards, now we just need to move that to an online editable medium like google docs.

Share this post


Link to post
Share on other sites

Ran the command in the first post on 2 cards on the Tinker Board running Ubuntu server. 
The Pro does seem faster in real life but appears to be throttled according to these results.

 

SanDisk EXTREME PRO 32G microsd
102400       4     2940     2979    12358    12454    11854     5106                                                          
102400      16     9973    10193    27494    27136    26774    14460                                                          
102400     512    50169    45212    54768    54786    54759    43162                                                          
102400    1024    51667    50141    55535    55509    55527    51758                                                          
102400   16384    56494    57656    62516    62519    62515    54816

 

SanDisk EXTREME 32G microsd
102400       4     3295     3386    12895    12944    11334     5094                                                          
102400      16    10249    10594    28429    28444    28299    12279                                                          
102400     512    46567    46915    54335    54433    54405    38604                                                          
102400    1024    52560    52806    55081    55182    55168    46654                                                          
102400   16384    54682    55071    62509    62525    62522    55492

Share this post


Link to post
Share on other sites

Anyone knows if cards with  A1 and A2 specs are available to buy.

 

A1 have random IO 1500 IOPS & 500 IOPS

A2 have random IO 4000 IOPS & 2000 IOPS

 

Any of the existing sd cards match this specs?

 

Share this post


Link to post
Share on other sites

test setup: opi+2e, 3.4.113, ondemand governor, running from ramdisk. header:

Spoiler

   Iozone: Performance Test of File I/O
                Version $Revision: 3.429 $
                Compiled for 32 bit mode.
                Build: linux

        Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
                     Al Slater, Scott Rhine, Mike Wisner, Ken Goss
                     Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
                     Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
                     Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone,
                     Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root,
                     Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer,
                     Vangel Bojaxhi, Ben England, Vikentsi Lapa.

        Run began: Wed Jun  7 10:34:26 2017

        Include fsync in write timing
        O_DIRECT feature enabled
        Auto Mode
        File size set to 102400 kB
        Record Size 4 kB
        Record Size 16 kB
        Record Size 512 kB
        Record Size 1024 kB
        Record Size 16384 kB
        Command line used: iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2
        Output is in kBytes/sec
        Time Resolution = 0.000001 seconds.
        Processor cache size set to 1024 kBytes.
        Processor cache line size set to 32 bytes.
        File stride size set to 17 * record size.

 

card info:

cid : 035344534c30384780d1f92540011269
csd : 400e00325b5900003b377f800a4040af
date : 02/2017
erase_size : 512
fwrev : 0x0
hwrev : 0x8
manfid : 0x000003
name : SL08G
oemid : 0x5344

 

 

card was bought from xunlong's store. white, red logo, black text, 8GB U1 C10 HCI, "made in china"

sandisk-industrial-8gb-opip2e-internal:
                                                              random    random
              kB  reclen    write  rewrite    read    reread    read     write
          102400       4     1907     1998     6985     6813     6093      832
          102400      16     6830     7020    13507    13420    13316       47
          102400     512     9996    11927    20052    20040    20004     1549
          102400    1024    10655    12051    20906    20930    20937     2958
          102400   16384    11725    12421    22239    22235    22179    11776
sandisk-industrial-8gb-opip2e-usbreader:
                                                              random    random     
              kB  reclen    write  rewrite    read    reread    read     write     
          102400       4     1995     2017     4495     4497     4462      863
          102400      16     7085     7147    10656    10669    10284       47
          102400     512    10271    10989    17790    17763    17745     1523
          102400    1024    10724    11145    18054    18050    18007     2937
          102400   16384    10873    11120    18679    18640    18671     9767

 

Share this post


Link to post
Share on other sites

I'm guessing this must be using a better binned MLC flash. Don't know about random performance though.

 

Is there any particular reason why you're worried about endurance ?

Share this post


Link to post
Share on other sites

 

opi0+2H3 8GB emmc:

                                                              random    random
              kB  reclen    write  rewrite    read    reread    read     write
          102400       4     5350     5923    12191    12233     9453     5861
          102400      16    17258    19735    28225    27445    24999    18945
          102400     512    36332    34508    59980    60008    59936    33483
          102400    1024    34079    35472    61459    61508    61546    33952
          102400   16384    36899    36954    67638    67631    67605    36413

 

Share this post


Link to post
Share on other sites
2 hours ago, kotc said:

opi0+2H3 8GB emmc

Settings matter (especially if ondemand is used). Without settings known (or better switching to performance governor prior to testing) these are just numbers without meaning (pretty nice ones though, but this eMMC should get close to 80MB/s sequential read speeds)

Share this post


Link to post
Share on other sites

I bought two new SD-Card (Samsung Evo Select 32GB, ~13$), since they're not available here I bought them from amazon. A review claimed that their random write performance should be good, whenever the card has no A1 rating.  The packaging looks original, but can't guarantee it.  :P H2testw looked ok (my SD-card reader on the notebook is internally connected via USB2 so forget about read performance here :D ).

Spoiler

Achtung: Nur 30530 von 30531 MByte getestet.
Fertig, kein Fehler aufgetreten.
Sie können die Testdateien *.h2w jetzt löschen oder nach Belieben
nochmals überprüfen.
Schreibrate: 19,1 MByte/s
Leserate: 33,4 MByte/s
H2testw v1.4

So, I mounted this card on my OPi PC plus (armbian on eMMC) and did a first iozone which didn't looked promising. Random write 4k of about 850kB (3x). Slightly annoyed, I burned armbian for the tinker board on this card and gave it another try.  Iozone looked not perfect, but ~50% faster. So, I thought this could be interesting, since a lot of numbers are presented here and the used SBC can have an impact on performance. Luckily, iozone has the possibility to save results in an excel file, because I'm definitely too lazy to play the copy paste monkey. A small bash script and some statistics did the rest (in principle, it's @tkaiser iozone test 50 times repeated).  

Spoiler

#!/bin/bash
x=50; 
while [ $x -gt 0 ]; 
do  iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 -b /home/opi/data/output$x.xls; 
x=$(($x-1)); 
done

 

So, here are my findings for the Samsung EVO Select SD-Card:

random4k.jpg.f2487a3c9b9589a7b9111b69ad681355.jpg

Posting the whole dataset would be an overkill so I only show you the random 4k write performance (if someone is interested, the whole dataset is available). Cause, they are some claimings about the performance of f2fs and btrfs, I formatted this card also with this two filesystems and gave them a try. All these measurements were made with the same SD-Card (I also tested the other one, but not 50x with all filesystems and the results looked similar). Since thomas noted that performance tests should run at min 1008MHz, the tests were repeated by cpu min freq. 1008MHz on the opi (setting cpu min on my tinker led to a non bootable system :D) For those who are not familiar with this type of diagram, it's a box plot and wikipedia explains it quite good. We see that f2fs doesn't differ that much in performance but btrfs seems to be faster (but variation is also much higher!).  

 

To be complete:

ARMBIAN 5.32.170629 nightly Ubuntu 16.04.2 LTS 4.11.7-sun8i (OrangePi PC+)

Armbian_5.30_Tinkerboard_Ubuntu_xenial_default_4.4.71_desktop ((Tinker, latest stable legacy from download page)

 

 

Share this post


Link to post
Share on other sites
2 hours ago, chwe said:

a lot of numbers are presented here and the used SBC can have an impact on performance

 

The used SBC has an influence since it bottlenecks the tests by card interface and maybe also CPU. The used OS has an influence since it bottlenecks the tests by default cpufreq scaling settings.

 

That's the reason the numbers on page 1 were all done with the same device and same settings (performance governor, everything explained in the 1st post in 'Preparations' section at the top). Most SBC (all Allwinner based) show a transfer speed limitation due to SDIO interface between SoC and card (so sequential transfer speeds are limited to ~23MB/s anyway and this same limitation also bottlenecks random performance number of very fast cards). But since most SBC are bottlenecked by this interface limitation numbers are also quite realistic.

 

The exceptions to this rule are Raspberries (where you can 'overclock' the SD card interface if you hate your data), the Tinkerboard, almost all ODROIDs and in general most newer boards like ROCK64. 

 

But as usual settings matter a lot, see this example here with different minimum cpufreq settings (affecting cpufreq scaling latency to reach higher clockspeeds which are needed for good IO performance): https://tinkerboarding.co.uk/forum/thread-310.html

 

In other words: Most user contributed numbers here are for the bin if they're not accompanied by a clearly documented test procedure (which board, which kernel variant, which cpufreq governor -- everything else than performance and the numbers don't tell anything about the SD card or eMMC any more -- and which cpufreq scaling limits)

Share this post


Link to post
Share on other sites
6 hours ago, tkaiser said:

SoC and card (so sequential transfer speeds are limited to ~23MB/s anyway

That was clear, and also visible on this card, I get seq. read of ~60MB/s wit h this cards on the tinker. But what's interesting to me: Why does random write 4k differs so much between btrfs and ext4? Why is there such a big standard deviation on btrfs? Since there's a discussion here that btrfs would be a possibility for root fs this could be interesting? Or am I totally wrong?

Share this post


Link to post
Share on other sites
14 minutes ago, chwe said:

Why does random write 4k differs so much between btrfs and ext4?

 

Since 'benchmarking gone wrong': https://www.cnx-software.com/2017/06/18/nanopi-neo-nas-kit-review-assembly-openmediavault-installation-setup-and-benchmarks/#comment-543160 (btrfs and iozone's 'direct IO' mode don't match so you get numbers without meaning since not 'disk' performance is measured but mostly filesystem performance due to buffering)

Share this post


Link to post
Share on other sites

OPZ (v1.4) H2+ 512MB

Linux orangepizero 3.4.113-sun8i #4 SMP PREEMPT Wed Nov 22 13:45:28 CET 2017 armv7l GNU/Linux

Sandisk Ultra 16GB UHS-1 A1 (brand new)

 

Command line used: iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2

 

                                                                                             random  random

                  kB    reclen      write    rewrite       read    reread       read      write

          102400           4      4178      4218      7990      7980      6558      4216                                                          
          102400         16      4182      7258    15836    15842    14401      8915                                                          
          102400       512    10306    13813    22836    22849    22691    15488                                                          
          102400     1024    15984    15258    22875    22889    22849    19105                                                          
          102400   16384    14680    15898    22979    22963    22982    17427

Share this post


Link to post
Share on other sites
10 hours ago, Moklev said:

Command line used: iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2

 

Settings matter as already explained above. I would assume after switching to performance cpufreq governor some numbers look different/better?

sudo cpufreq-set -g performance

 

Share this post


Link to post
Share on other sites

Ok...

 

OPZ (v1.4) H2+ 512MB (Debian Jessie)

Linux orangepizero 3.4.113-sun8i #4 SMP PREEMPT Wed Nov 22 13:45:28 CET 2017 armv7l GNU/Linux

Sandisk Ultra 16GB UHS-1 A1 (brand new, EXT4)

 

Governor: standard, on demand

 

Spoiler

francesco@orangepizero:~$ iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2
    Iozone: Performance Test of File I/O
            Version $Revision: 3.429 $
        Compiled for 32 bit mode.
        Build: linux

    Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
                 Al Slater, Scott Rhine, Mike Wisner, Ken Goss
                 Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
                 Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
                 Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone,
                 Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root,
                 Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer,
                 Vangel Bojaxhi, Ben England, Vikentsi Lapa.

    Run began: Thu Jan 11 14:28:25 2018

    Include fsync in write timing
    O_DIRECT feature enabled
    Auto Mode
    File size set to 102400 kB
    Record Size 4 kB
    Record Size 16 kB
    Record Size 512 kB
    Record Size 1024 kB
    Record Size 16384 kB
    Command line used: iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2
    Output is in kBytes/sec
    Time Resolution = 0.000001 seconds.
    Processor cache size set to 1024 kBytes.
    Processor cache line size set to 32 bytes.
    File stride size set to 17 * record size.
                                                              random    random     bkwd    record    stride                                    
              kB  reclen    write  rewrite    read    reread    read     write     read   rewrite      read   fwrite frewrite    fread  freread
          102400       4     4146     3973     7829     7787     6458     3994                                                          
          102400      16     3689     8070    15331    15334    13764     8992                                                          
          102400     512    15845    10018    22645    21610    21711    14864                                                          
          102400    1024    17111    14468    22770    22769    22730    19262                                                          
          102400   16384    15860    14928    22882    22866    22865    18996                                                          

iozone test complete.

 

Governor: performance

 

Spoiler

francesco@orangepizero:~$ sudo cpufreq-set -g performance
francesco@orangepizero:~$ iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2
    Iozone: Performance Test of File I/O
            Version $Revision: 3.429 $
        Compiled for 32 bit mode.
        Build: linux

    Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
                 Al Slater, Scott Rhine, Mike Wisner, Ken Goss
                 Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
                 Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
                 Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone,
                 Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root,
                 Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer,
                 Vangel Bojaxhi, Ben England, Vikentsi Lapa.

    Run began: Thu Jan 11 14:34:47 2018

    Include fsync in write timing
    O_DIRECT feature enabled
    Auto Mode
    File size set to 102400 kB
    Record Size 4 kB
    Record Size 16 kB
    Record Size 512 kB
    Record Size 1024 kB
    Record Size 16384 kB
    Command line used: iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2
    Output is in kBytes/sec
    Time Resolution = 0.000001 seconds.
    Processor cache size set to 1024 kBytes.
    Processor cache line size set to 32 bytes.
    File stride size set to 17 * record size.
                                                              random    random     bkwd    record    stride                                    
              kB  reclen    write  rewrite    read    reread    read     write     read   rewrite      read   fwrite frewrite    fread  freread
          102400       4     4203     4041     7902     7826     6522     4230                                                          
          102400      16     4119     7783    15384    15386    14056    10029                                                          
          102400     512     8787    16740    22769    22767    22603    18208                                                          
          102400    1024    16362    15254    22781    22774    22735    19212                                                          
          102400   16384    16928    14003    22926    22927    22909    19130                                                          

iozone test complete.

 

Sandisk ultra A1 perform quite well in 4k zone and in random write (compared to a standard UHS-1 card Sandisk, Lexar, Kigston, etc...). Same performance in 512-16384k zone (Vs Kingston 8GB C10 UHS-1.)

 

 

Share this post


Link to post
Share on other sites
33 minutes ago, Moklev said:

Sandisk ultra A1 perform quite well in 4k zone and in random write (compared to a standard UHS-1 card Sandisk, Lexar, Kigston, etc...). Same performance in 512-16384k zone (Vs Kingston 8GB C10 UHS-1.)

 

Well, choosing Allwinner's dog slow SD card interface is most probably not the right platform to draw any such conclusions. It would need one of the other boards that are able to negotiate higher speed modes to fully 'benchmark' such a card since the bottlenecked interface between host and card influences all numbers.

 

Besides that thanks for the heads-up. I just checked prices and availability of these SanDisk A1 cards and this doesn't look too bad: https://geizhals.de/?fs=Sandisk+"UHS-I+A1"&in= -- when it's time to buy SD cards again I'll skip Samsung EVO this time and check the SanDisk cards instead :)

Share this post


Link to post
Share on other sites
3 hours ago, tkaiser said:

Besides that thanks for the heads-up. I just checked prices and availability of these SanDisk A1 cards and this doesn't look too bad: https://geizhals.de/?fs=Sandisk+"UHS-I+A1"&in= -- when it's time to buy SD cards again I'll skip Samsung EVO this time and check the SanDisk cards instead :)

 

Ya... but for a small order (1-2 cards) Amazon is the best option. I've purchased a single Sandisk Ultra A1 16GB for 10,50€ (inc. VAT, inc. ship. by Amazon Italy).

Share this post


Link to post
Share on other sites

2018 SD card update

 

It's 2018 now, SD Association's A1 'performance class' spec is out over a year now and in the meantime we can buy products trying to be compliant to this performance class. SD cards carrying the A1 logo must be able to perform at least 1500 random read input-output operations per second (IOPS) with 4KB block size, 500 random write IOPS and 10 MB/s sustained sequential performance (see here for more details and background info)

 

Why is this important? Since what we do on SBC at least for the rootfs is mostly random IO and not sequential IO as it's common in cameras or video recorders (that's the stuff SD cards have been invented to be used with in the beginning). As an SBC (or Android) user we're mostly interested in high random IO performance with smaller blocksizes since this is how 'real world' IO patterns mostly look like. Prior to A1 and A2 performance classes there was no way to know how SD cards perform in this area prior to buying. Fortunately this has changed now.

 

Last week arrived an ODROID N1 dev sample so I bought two SanDisk A1 cards with 32GB capacity each. An el cheapo 'Ultra A1' for 13€ (~$15) and an 'Extreme A1' for 23€. I wanted to buy a slightly more expensive 'Extreme Plus A1' (since even more performance and especially reliability/longevity) but ordered the wrong one :( Please keep in mind that the 'Extreme Plus' numbers shown below are made with an older card missing the A1 logo.

 

Let's look how these things perform, this time on a new platform: RK3399 with an SD card interface that supports higher speed modes (requires kernel support and switching between 3.3V to 1.8V at the hardware layer). So results aren't comparable with the numbers we generated the last two years in this and other threads but that's not important any more... see at the bottom.

 

A1 conformance requires at least 10 MB/s sequential performance and 500/1500 (write/read) IOPS with 4K blocksize. I tested also with 1K and 16K blocksizes for the simple reason to get an idea whether 4K results are useful to determine performance with smaller or larger blocksizes (since we already know that the vast majority of cheap SD cards out there shows a severe 16K random write performance drop which is the real reason so many people consider all SD cards being crap from a performance point of view).

 

I tested with 7 cards, 4 of them SanDisk, two Samsung and the 'Crappy card' being a results mixture of a 4GB Kingston I started to test with and old results from a 4GB Intenso from two years ago (see first post of this thread). The Kingston died when testing with 4K blocksize and the performance of all these crappy 'noname class' cards doesn't vary that much:

                         1K w/r        4K w/r        16K w/r
   Crappy card 4GB      32  1854      35  1595        2   603
Samsung EVO+ 128GB     141  1549     160  1471      579  1161
     Ultra A1 32GB     456  3171     843  2791      548  1777
   Extreme A1 32GB     833  3289    1507  3281     1126  2113
  Samsung Pro 64GB    1091  4786    1124  3898      478  2296
 Extreme Plus 16GB     566  2998     731  2738      557  2037    
   Extreme Pro 8GB     304  2779     323  2754      221  1821

(All results in IOPS --> IO operations per second)

For A1 compliance we only need to look at the middle column and have to expect at least 500/1500 IOPS minimum here. The 'Crappy card' fails as expected, the Samsung EVO+ too (but we already knew that for whatever reasons newer EVO+ or those with larger capacity perform worse than the 32GB and 64GB variants we tested two years ago), the Samsung Pro shows the best performance here while one of the 4 SanDisk also fails. But my Extreme Pro 8GB is now 3 years old, the other one I had showed signs of data corruption few months ago and when testing 2 years ago (see 1st post in this thread) random write performance was at 800. So most probably this card is about to die soon and the numbers above are partially irrelevant..

 

What about sequential performance? Well, 'Crappy card' also not able to meet specs and all the better cards being 'bottlenecked' by ODROID N1 (some of these cards show 80 MB/s in my MacBook's card reader but Hardkernel chose to use some safety headroom for good reasons and limits the maximum speed for improved reliability)

                           MB/s write     MB/s read
   Crappy card 4GB              9            15
Samsung EVO+ 128GB             21            65
     Ultra A1 32GB             20            66
   Extreme A1 32GB             59            68
  Samsung Pro 64GB             61            66
 Extreme Plus 16GB             63            67
   Extreme Pro 8GB             50            67

Well, sequential transfer speeds are close to irrelevant with single board computers or Android but it's good to know that boards that allow for higher SD card speed modes (e.g. almost all ODROIDs and the Tinkerboard) also show an improvement in random IO performance if the card is a good one. The ODROID N1 was limited to DDR50 (slowest SD card mode) until today when Hardkernel unlocked UHS capabilities so that my cards (except of 'Crappy card') could all use SDR104 mode. With DDR50 mode sequential performance is limited to 22.5/23.5MB/s (write/read) but more interestingly random IO performance also differs. See IOPS results with the two SanDisk A1 cards, one time limited to DDR50 and then with SDR104:

                        1K w/r        4K w/r        16K w/r
  Ultra A1  DDR50     449  2966     678  2191      445   985
  Ultra A1 SDR104     456  3171     843  2791      548  1777

                        1K w/r        4K w/r        16K w/r
Extreme A1  DDR50     740  3049    1039  2408      747  1068
Extreme A1 SDR104     833  3289    1507  3281     1126  2113

We can clearly see that the larger the blocksize the more the interface speed influences also random IO performance (look especially at 16K random reads that double with SDR104)

 

Some conclusions:

  • When comparing results above the somewhat older Samsung Pro performs pretty similar to the Extreme A1. But great random IO performance is only guaranteed with cards carrying the A1 logo (or A2 soon) so it might happen to you that buying another Samsung Pro today results in way lower random IO performance (see Hardkernel's results with a Samsung Pro Plus showing 224/3023 4k IOPS which is way below the 1124/3898 my old Pro achieves with especially write performance 5 times worse and below A1 criteria)
  • We still need to focus on the correct performance metrics. Sequential performance is more or less irrelevant ('Class 10', 'UHS' and so on), all that matters is random IO (A1 and A2 soon). Please keep in mind that you can buy a nice looking UHS card from 'reputable' brands like Kingston, Verbatim, PNY and the like that might achieve theoretical 80MB/s or even 100MB/s sequential performance (you're not able to benefit from anyway since your board's SD card interface will be the bottleneck) but simply sucks with random IO performance. We're talking about up to 500 times worse performance when trusting in 'renowned' brands and ignoring performance reality (see 16k random writes comparing 'Crappy card' and 'Extreme A1')
  • Only a few vendors on this planet run NAND flash memory fabs, only a few companies produce flash memory controllers and have the necessary know-how in house. And only a few combine their own NAND flash with their own controllers to their own retail products. That's the simple reason why at least I only buy SD cards from these 4 brands: Samsung, SanDisk, Toshiba, Transcend
  • The A1 performance speed class is a great and necessary improvement since now we can rely on getting covenant random IO performance. This also helps in fighting counterfeit flash memory products since even if fraudsters in the meantime produce fake SD cards that look real and show same capacity usually these fakes suck at random IO performance. So after testing new cards with either F3 or H2testw it's now another iozone or CrystalDiskMark test to check for overall performance including random IO (!) and if performance sucks you simply return the cards asking for a refund.

TL;DR: If you buy new SD cards choose those carrying an A1 or A2 logo. Buy only good brands (their names start with either S or T). Don't trust in getting genuine products but always expect counterfeit stuff. That's why you should only buy at sellers with a 'no questions asked' return/refund policy and why you have to immediately check your cards directly after purchase. If you also care about reliability/resilience buy more expensive cards (e.g. the twice as expensive Extreme Plus A1 instead of Ultra A1) and choose larger capacities than needed.

 

Finally: All detailed SD card test results can be found here: https://pastebin.com/2wxPWcWr As a comparison performance numbers made with same ODROID N1, same settings but vendor's orange eMMC modules based on Samsung eMMC and varying only in size: https://pastebin.com/ePUCXyg6

Share this post


Link to post
Share on other sites