10 10
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

 

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

Since A1 or A2 rated cards are the only reasonable choice any more for SD and TF cards here a dynamic link to a German price comparison portal that allows for filtering of results. Only A1 rated cards with at least 10 years warranty shown: https://geizhals.de/?cat=sm_sdhc&xf=5531_10~5963_A1&sort=p#productlist (Google Translate version).

 

At the time of this writing only some SanDisk A1 and Strontium A1 cards are listed there but I hope this will change soon.

 

Please remember: Only with cards that claim to be compliant to A1 or A2 specifications it's ensured that random IO performance doesn't suck. It's important to have an eye on A1 and A2 logos since why buying SD cards any more that perform worse?

Share this post


Link to post
Share on other sites

Tests 1 and 3 SanDisk Ultra 32 Gig USB 3.0

 

Test 3
    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     bkwd    record    stride                                    
              kB  reclen    write  rewrite    read    reread    read     write     read   rewrite      read   fwrite frewrite    fread  freread
          102400       4     3643     3837    15912    17240     6657     1862                                                          
          102400      16     8846    10894    46156    39563    23035     5752                                                          
          102400     512    16001    31029   124890   123804    89134    13110                                                          
          102400    1024    29149    32220   124968   126517   101223    23571                                                          
          102400   16384    30933    31919   129874   131508   128952    27569

 

Test 1

                                                              random    random     bkwd    record    stride                                    
              kB  reclen    write  rewrite    read    reread    read     write     read   rewrite      read   fwrite frewrite    fread  freread
          102400       4     3424     3576    17552    17333     5964     1901                                                          
          102400      16    10877    12941    49304    51328    24291     3688                                                          
          102400     512    15854    30037   124458   104809    87279    10882                                                          
          102400    1024     9529    31652   126718   127313   101724    12027                                                          
          102400   16384    31277    18267   129123   128771   128144    33082 

 

                                                              

 

Share this post


Link to post
Share on other sites

I saw that you tested a SanDisk Extreme Pro 64GB - A2 card with ext4 and didn't get the expected results (https://github.com/ThomasKaiser/Knowledge/blob/master/articles/A1_and_A2_rated_SD_cards.md)

 

I tested my SanDisk Extreme Pro A2 256GB micro with A2 logo (bought beginning of October 2018), formatted ExFAT under MacOS 10.14 (iozone installed via homebrew). I thought this might be interesting for you:

 

Test 1:

                                                              random    random     bkwd    record    stride                                    
              kB  reclen    write  rewrite    read    reread    read     write     read   rewrite      read   fwrite frewrite    fread  freread
          102400       1    71735    74819   750573   769362   416685    61419                                                                
          102400       2    72975    74808  1324810  1342211   787443    65213                                                                
          102400       4    74887    76056  2067185  2154206  1440308    67627                                                                
          102400      16    75828    76580  3978854  3807129  3004696    70542                                                                
          102400     128    70181    75891  5519047  5797444  4493592    70074                                                                
          102400     512    76834    76954  5866896  5991461  5061787    71180                                                                
          102400    1024    79300    79602  5903994  4940446  5571237    72008                                                                
          102400   16384    82960    82502  6244310  5044075  6105069    75332 

 

Test 2:

                                                              random    random     bkwd    record    stride                                    
              kB  reclen    write  rewrite    read    reread    read     write     read   rewrite      read   fwrite frewrite    fread  freread
          102400       1    72111    74632   706436   714325   388037    60997                                                                
          102400       2    75580    74301  1283544  1363348   783629    64232                                                                
          102400       4    76621    75244  2168159  2201398  1419623    66416                                                                
          102400      16    76340    77138  4087649  3789092  3370748    69204                                                                
          102400     128    75380    75991  5518693  4827877  5774217    71572                                                                
          102400     512    63009    77769  5990458  5759273  5894918    66458                                                                
          102400    1024    73595    68298  5961108  5981698  6634301    62683                                                                
          102400   16384    72310    72862  5990121  6236754  6470780    68542

 

Test 3:

                                                              random    random     bkwd    record    stride                                    
              kB  reclen    write  rewrite    read    reread    read     write     read   rewrite      read   fwrite frewrite    fread  freread
          102400       1    72706    72637   767523   787172   422875    61073                                                                
          102400       2    73304    73348  1330300  1374293   800613    64702                                                                
          102400       4    72564    74550  2140561  2198186  1445840    67664                                                                
          102400      16    72701    76324  4004190  3749432  3430462    69190                                                                
          102400     128    74825    76603  5780123  5851070  4953780    70198                                                                
          102400     512    76477    76923  5890148  5900993  5225541    71628                                                                
          102400    1024    77942    80417  5930079  5984115  5487737    72037                                                                
          102400   16384    82740    82455  5965766  5569606  6449524    74115

 

 

Share this post


Link to post
Share on other sites

hmm the numbers looking for me like a magnitude to high.. :wacko: (at least)..  Sure you didn't benchmark your SSD (even then, apple must have nice SSDs in their notebooks :P)? and/or there's some caching still active (but even then it looks to high for me). 

Share this post


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

 

hmm the numbers looking for me like a magnitude to high.. :wacko: (at least)..  Sure you didn't benchmark your SSD (even then, apple must have nice SSDs in their notebooks :P)? and/or there's some caching still active (but even then it looks to high for me). 

 

I was also really surprised by the numbers.

 

In the Terminal I navigated to a folder on the SD card and then issued the command. In a testing run I could see that there are temporary files created and deleted in that folder. So to me it looks like it was running on the SD Card. I have no idea how to switch caching off on Mac OS. Is there anything else I can do to prove that the test is running on the SD Card?

 

The Card is plugged into the internal SD Card Reader of my MacBook Pro 11,4 (15 inch, mid 2015).

 

EDIT: I‘ll try this, when I get back home after work today:

https://superuser.com/questions/113019/is-it-possible-to-disable-write-caching-on-a-usb-mass-storage-device-on-mac-os-x#115640

Edited by Bernie_O

Share this post


Link to post
Share on other sites

I used this command to mount with write caching disabled:

mount_exfat -o nodev,nosuid,noowners,noasync /dev/disk2s1 testmount

 

still similar output (see attached file "storage-report"). Grml...

 

I then did a very basic sequential test of writing 5GB to get a rough idea of sequential speed with:

sh-3.2# time sh -c "dd if=/dev/zero of=testfile bs=100k count=50k && sync"
51200+0 records in
51200+0 records out
5242880000 bytes transferred in 61.054574 secs (85872027 bytes/sec)

real    1m2.059s
user    0m0.114s
sys    0m2.953s

So the sequential write speed seems kind of realistic to me (5.242,880000 / 62,059sec = 84,482Mbytes/second)

The same command takes on the intenal SSD only 4,7 seconds real time. Wow!

 

But I still don't have any clue why the iozone tests give such unrealistic results on the SD card...

 

Attached file:

storage-report.txt

Share this post


Link to post
Share on other sites
10 10