Jump to content

Testers wanted: SD card performance

tkaiser

By tkaiser
in Beginners

 Share

Recommended Posts

lampra

lampra

Posted
Posted

Here is a used Toshiba EXCERIA 16GB

I have run izone on cubietruck with an other image (not Armbian) already on the card

Photo

 

  Reveal hidden contents

 

 

  Reveal hidden contents

 

tkaiser

tkaiser

Posted
  • Author
Posted
  On 5/2/2016 at 10:05 PM, lampra said:

Here is a used Toshiba EXCERIA 16GB

 

Thx. But it would help if you could tell the exact product description (also for the Transcend tested before), maybe an picture of those two cards?

 

IMO they're both too slow (especially writes and especially with small record sizes) but since they're both rather old the results are hard to classify or to use for buying decisions.

lampra

lampra

Posted
Posted
  On 5/3/2016 at 6:29 AM, tkaiser said:

Thx. But it would help if you could tell the exact product description (also for the Transcend tested before), maybe an picture of those two cards?

 

IMO they're both too slow (especially writes and especially with small record sizes) but since they're both rather old the results are hard to classify or to use for buying decisions.

Hi, both posts updated with a photo. I bought both cards during 2015 and I now realized that they were manufactured during 2012 and 2013.

When it comes to desktop use (i.e. "not headless"), Toshiba exceria is much more responsive and also much faster with software updates.

If you think that these posts are "useless" even for future reference, let me know and I can delete them.

1
drose28357

drose28357

Posted
Posted

i just installed Armbian Jessie Desktop Vanilla (Kernel 4.5.2-sunxi) on a cubietruck

i moved rootfs to ssd.

I use SanDisk Extrem Pro U3 64 GByte. It loads the image on USB3.0 with 75 Mbyte/sec. So it should be a speedy one ;-)

 

here are the result

/var/log/armhwinfo.log has been uploaded to http://sprunge.us/HQKV
 

                                                              random    random     bkwd    record    stride                                    
              kB  reclen    write  rewrite    read    reread    read     write     read   rewrite      read   fwrite frewrite    fread  freread
          102400       4    10685    13846    38298    39802    22382    13571                                                          
          102400      16    20769    24279    70019    71756    58212    24283                                                          
          102400     512    34010    34755   150473   150265   146174    35034                                                          
          102400    1024    34605    35535   154435   155517   152905    35198                                                          
          102400   16384    36256    36648   176087   176085   176053    36368

and from "cat /var/log/armhwinfo.log | more"

Fri Apr 29 03:16:19 CEST 2016 sun7i armv7l  Cubietech Cubietruck Cubietruck
Linux version 4.5.2-sunxi (root@trusty) (gcc version 4.8.4 (Ubuntu/Linaro 4.8.4-2ubuntu1~14.04.1) ) #11 SMP Thu Apr 28 21:53:25$
### mmc0:aaaa info:

                 cid: 0353445350363447802a34340700fa37 
                 csd: 400e00325b590001dbd37f800a4040df 
                 scr: 0245840300000000 
                date: 10/2015 
                name: SP64G 
                type: SD 
preferred_erase_size: 16777216 
               fwrev: 0x0 
               hwrev: 0x8 
               oemid: 0x5344 
              manfid: 0x000003 
              serial: 0x2a343407 
              uevent: DRIVER=mmcblk MMC_TYPE=SD MMC_NAME=SP64G MODALIAS=mmc:block 
          erase_size: 512
tkaiser

tkaiser

Posted
  • Author
Posted
  On 5/5/2016 at 10:50 AM, drose28357 said:

i moved rootfs to ssd.

 

And tested the SSD later :)

 

Please note that the Cubietruck can not exceed 23MB/s on SDIO and not 39.5MB/s on USB2.0 so you showed us how your SSD performs when using native SATA. Performance is not that impressive so maybe look through http://linux-sunxi.org/Sunxi_devices_as_NAS  :)

1
tkaiser

tkaiser

Posted
  • Author
Posted
  On 5/6/2016 at 1:39 PM, drose28357 said:

Sorry. didnt understand the test command. But it seems to create a file maybe in rootfs ( :o on ssd). 

 

Well, iozone uses the current working directory to test with. So in case you created an ext4 partition on your SD card that is writeable simply do a chdir before and then start the iozone call again. Regarding your Samsung SSD 840 EVO. You should be able to exceed 40MB/s sequential write speeds and get close to 200MB/s. Which cpufreq governor are you currently using (cpufreq-info should tell)?

wildcat_paris

wildcat_paris

Posted
Posted

my turn with eMMC 32GB from hardkernel (without the SD reader) Odroid XU4 kernel 3.10.96

 

 

  Reveal hidden contents

 

 

MMC info:

 

  Reveal hidden contents

 

sooperior

sooperior

Posted
Posted

Hi,

My results: http://sprunge.us/KLWN

Using the image provided for this test, no modifications

Hardware: Banana pi M1

Card Samsung EVO+ 32 gb U1

 

Quick comment: could it be possible to make a script (e.g. testsd) with the command? I think I did it the right way but there is a risk of inputting the wrong parameters

 

Hope it helps!

post-993-0-20758300-1463217930_thumb.jpg

tkaiser

tkaiser

Posted
  • Author
Posted
  On 5/14/2016 at 9:30 AM, sooperior said:

could it be possible to make a script (e.g. testsd) with the command? I think I did it the right way but there is a risk of inputting the wrong parameters

 

Thx for the suggestion. Next time I'm rolling out such a test image I will keep that in mind. Currently you could use 'armbianmonitor -c $HOME' to do this performance test (given $HOME is located on the SD card). But since the -c switch (check) has been designed to test also the reliability of the card this check can take a long time since all available free space will be tested (by f3write/f3read).

 

BTW: Next time we should also consider 32K test size since the many test runs showed some abnormal random write results with 16K (many many cards really suck here) and 32K is now Firefox/Midori default Sqlite page size ('browsing the web' with Firefox/Midori means constant random 32K writes and in case an SD card is used that's slow here browser processes are constantly stuck in IO)

 

BTW: Is it just me but I'm missing your actual test results?

eternalWalker

eternalWalker

Posted
Posted

... eMMC BMPi3 with sinovoip's "dietpi" Image (dietpi-preview-bpi-m3-sd-emmc.image 2016-5-14 )

 

root@BPiM3:~# uname -a
Linux BPiM3 3.4.39-BPI-M3-Kernel #1 SMP PREEMPT Tue May 3 13:47:01 UTC 2016 armv7l GNU/Linux

       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     3224     4963     9150     9159     8220     3634
          102400      16     7474     6181    21394    21420    20109     4830
          102400     512     6893     7747    55980    41569    39409     7147
          102400    1024     7160     7378    41020    46033    46022     7989
          102400   16384     8332     7606    61326    61396    60390     7694

...& Flash Information:

mmc1:0001 info:

                 cid: 15010038575044335200e79f654a13ad
                 csd: d02701320f5903fff6dbffef8e40400d
                 rev: 7
                date: 01/2000
                name: 8WPD3R
                type: MMC
preferred_erase_size: 524288
          cache_ctrl: 0
          cache_size: 65536
               fwrev: 0x0
               hwrev: 0x0
               oemid: 0x0100
enhanced_area_offset: 18446744073709551594
              manfid: 0x000015
              serial: 0xe79f654a
              uevent: DRIVER=mmcblk MMC_TYPE=MMC MMC_NAME=8WPD3R MODALIAS=mmc:block
          erase_size: 524288
  enhanced_area_size: 4294967274

root@BPiM3:~# cat /proc/sys/vm/mmap_min_addr
4096

Great from Austria

 

@tkaiser

have you the image (Semi_Armbian_5.07_M3) like minimal?  Without X? Thx. (ich putze nich gerne :P  ) Thx in advance   :beer: 

tkaiser

tkaiser

Posted
  • Author
Posted
  On 5/14/2016 at 10:55 PM, eternalWalker said:

@tkaiser

have you the image (Semi_Armbian_5.07_M3) like minimal?  Without X? Thx. (ich putze nich gerne :P  ) Thx in advance   :beer:

 

Nope, but as outlined in moronic BPi forum you can combine any rootfs with SinoVoip's OS images (that's what they do all day long) so you can take any sun8i Armbian image and simply copy over the rootfs. Of course I would do it differently as outlined in H3 FAQ.

 

Regarding your test results: It seems there's something wrong. Either with the image you used (settings matter and that's the reason I provided a dedicated Armbian test image at the top of this thread) or with the eMMC they use now. At least when I tested half a year ago sequential write speeds were 3 times higher so I think your results are somewhat questionable or would at least need further investigation.

Igor

Igor

Posted
Posted

8G eMMC @Opi PC+

                                                              random    random
              kB  reclen    write  rewrite    read    reread    read     write
          102400       4     6262     6629    16402    16395    13807     6452
          102400      16    21461    22644    38815    38879    34878    21536
          102400     512    36555    36811    65848    65820    65757    35055
          102400    1024    37144    37141    70197    70151    70182    36506
          102400   16384    39586    39656    78985    78983    78905    39622

          102400       4     6305     6683    16485    16511    13938     6567
          102400      16    21586    22801    38892    39009    35094    21554
          102400     512    36563    36442    65146    65170    65086    35190
          102400    1024    36874    37237    70174    70158    70121    36484
          102400   16384    39602    39563    78982    78970    78993    39567
2
tkaiser

tkaiser

Posted
  • Author
Posted

Banana Pi M2+ running 3.4.112 @ 1200 MHz, 8GB eMMC:

                                                              random    random
              kB  reclen    write  rewrite    read    reread    read     write
          102400       4     5462     5780    13914    13919    11757     5667
          102400      16    18099    18741    35521    35393    31657    17903
          102400      32    20665    21437    45119    45499    42081    19926
          102400     512    25062    24884    63142    63277    63115    24127
          102400    1024    25252    25218    68877    68462    68330    24927
          102400   16384    26360    26356    77756    77808    77737    26345

Orange Pi Plus 2E running 3.4.112  @ 1296 MHz, 16GB eMMC:

                                                              random    random
              kB  reclen    write  rewrite    read    reread    read     write
          102400       4     6383     6803    16713    16728    14099     6749
          102400      16    22678    24012    39160    39164    35149    23221
          102400      32    29243    30099    48981    49041    45747    28385
          102400     512    38058    38255    63783    63322    63741    36899
          102400    1024    38556    38800    69013    69222    69085    38052
          102400   16384    41116    41587    78354    78300    78353    41108

Orange Pi Plus 2E running 4.6-rc1 @ 816 MHz only (no throttling yet available therefore 'play safe'), the same 16GB eMMC:

                                                              random    random
              kB  reclen    write  rewrite    read    reread    read     write
          102400       4     6501     6937    16680    16678    14042     6057
          102400      16    23547    24898    41205    41240    36901    23992
          102400      32    30655    31229    53485    53582    49688    29383
          102400     512    40405    40571    74903    74963    74322    27747
          102400    1024    40875    40914    75691    75750    75750    39958
          102400   16384    40900    41017    75927    76017    76009    40880

In other words: Xunlong uses faster eMMC than 'Team BPi' and mainline kernel results look promising. It seems in our 'latest' 4.6-rc1 kernel for H3 boards we already benefit from wens' eMMC HS-DDR support. The device tree nodes for eMMC on BPi M2+ and for the eMMC equipped Oranges all look already like this:

                        mmc2_8bit {
                                allwinner,pins = "PC5", "PC6", "PC8", "PC9", "PC10", "PC11", "PC12", "PC13", "PC14", "PC15", "PC16";
                                allwinner,function = "mmc2";
                                allwinner,drive = <0x3>;
                                allwinner,pull = <0x1>;
                                linux,phandle = <0x1b>;
                                phandle = <0x1b>;
                        };
1
wildcat_paris

wildcat_paris

Posted
Posted

[Pine64] A simple SanDisk 8GB Class 10 SDHC UHS-I Class 1

                                                              random    random
              kB  reclen    write  rewrite    read    reread    read     write
          102400       4     2010     1993     8440     8422     8422      876
          102400      16     7657     7513    16585    16622    16622       47
          102400     512    11608    12550    23140    23142    23108     1567
          102400    1024    12146    12519    23163    23164    23166     3001
          102400   16384    12079    13288    23195    23197    23194    12536

details

 

  Reveal hidden contents

 

Igor

Igor

Posted
Posted

Samsung 128GB EVO+ @Bananapi M2+ running 3.4.112

Low performance with small files.  :( http://sprunge.us/JhiI

                                                              random    random
              kB  reclen    write  rewrite    read    reread    read     write
          102400       4     1678     1711     3884     3861     3724      993
          102400      16     2418     2826    10531    10520     9911     2087
          102400     512    14170    16880    21360    21334    21319    11710
          102400    1024    16402    16584    21780    21777    21765    12249
          102400   16384    14908    17148    22618    22588    22584    14759
   
          102400       4     1613     1148     3890     3883     3809      940
          102400      16     4896     5697    10539    10539     9936     2818
          102400     512    16313    16380    21335    21332    21332    12171
          102400    1024    14629    16577    21886    21856    21845    12429
          102400   16384    14910    17201    22587    22617    22604    14910
                 cid: 1b534d303030303010db1b022600fb73 
                 csd: 400e00325b590003bdfd7f800a4000e5 
                 scr: 0245800300000000 
                date: 11/2015 
                name: 00000 
                type: SD 
preferred_erase_size: 4194304 
               fwrev: 0x0 
               hwrev: 0x1 
               oemid: 0x534d 
              manfid: 0x00001b 
              serial: 0xdb1b0226 
              uevent: DRIVER=mmcblk MMC_TYPE=SD MMC_NAME=00000 MODALIAS=mmc:block 
          erase_size: 512
tkaiser

tkaiser

Posted
  • Author
Posted

Interesting results from Beelink X2's internal eMMC. When I first tested I got results that look weird:

 

  Reveal hidden contents

 

 

First assumption: Overheating (Beelink X2 uses a heat pad on H3 and a large metal plate above so when the SoC shows 60°C most likely everything inside the enclosure is at 55°C). But a few tests confirmed: Nope, not temperature related but write performance drops drastically after continually writing large amounts of data (as our benchmarking does). So I tested with some time in between different runs and get somewhat decent performance numbers:

for i in 4k 16k 32k 512k 1024k 16384k; do
	iozone -e -I -a -s 100M -r $i -i 0 -i 1 -i 2 ; sleep 300
done
                                                              random    random
              kB  reclen    write  rewrite    read    reread    read     write
          102400       4     3478     3734    13374    13292     9872     3259
          102400      16     9991    10273    28856    28916    24218     9331
          102400      32    13963    18092    35374    35153    31823    13414
          102400     512    24717    24557    43647    43830    43396    23682
          102400    1024    25057    24814    45497    45714    45499    24591
          102400   16384    25597    25752    48003    48602    48390    26050

What does that mean for us: Beelink X2 as a data logger might be not the best idea but for normal use cases eMMC performance is ok. Would be great if other X2 owners would drop in their results. Both using the delayed approach as shown above as well as the usual:

echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
iozone -e -I -a -s 100M -r 4k -r 16k -r 32k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2
EtlARM

EtlARM

Posted
Posted

End of last year I received several faked Samsung EVO 32G, therefore I bought a Samsung Pro 32G:

 

Tested on CubieTruck, Armbian 5.11, ext4, card is used for 7 month, system is doing some minor background work.

 

 

  Reveal hidden contents


 

  Reveal hidden contents

 

tkaiser

tkaiser

Posted
  • Author
Posted
  On 7/5/2016 at 7:05 PM, EtlARM said:

End of last year I received several faked Samsung EVO 32G, therefore I bought a Samsung Pro 32G

 

Well, the results aren't impressive (way slower than EVO/EVO+ and Pro we already tested) and it's somewhat useless to measure when information about the amount of background activity is not available as well as cpufreq settings. That's why I provided an own test image in the first place... to be able to compare different hardware afterwards since every test happened with identical settings.

 

New results: neither SD card nor NAND/eMMC but an USB stick: "Samsung Memory Fit USB Flash Drive Speicherstick 128GB" bought for approx 45 bucks for a customer to double the storage capacity of his MacBook:

 

Samsung_128GB.jpg

 

Performance connected to the MacBook using USB 3.0 is quite ok, connected to an Orange Pi PC Plus (USB 2.0, performance cpufreq governor, ext4 without further tuning) it's not that great:

                                                              random    random
              kB  reclen    write  rewrite    read    reread    read     write
          102400       4     6719     4639     7289     7327     3325      673
          102400      16     8865    10110    17630    13126     9332     1738
          102400     512    15794     5296    30224    29691    20380     7460
          102400    1024    17655    21927    23763    30117    29757    10017
          102400   16384    29651    18520    31263    24585    31983    13342

Device info according to lsusb:

 

  Reveal hidden contents

 

 

But since the device is really small and other USB sticks I tested recently (Kingston, Verbatim and SONY) were magnitudes slower I decided to post results here in case anyone is searching for a low power solution requiring minimum space to add 128GB to his SBC.

1
RagnerBG

RagnerBG

Posted
Posted

I just got this:

 

 

  Reveal hidden contents

 

 

It's advertise as UCH-I U3, r - up to 90Mb/s, w - up to 40Mb/s. The result are a bit diferent:

                                                              random    random
              kB  reclen    write  rewrite    read    reread    read     write
          102400       4     2644     2714     8684     8683     8641     2420
          102400      16     7870     8483    16670    16686    16645     6124
          102400     512    19282    21706    22715    22722    22716    20974
          102400    1024    22048    22177    22886    22887    22884    21872
          102400   16384    22199    22247    22956    22957    22957    22235

### mmc0:aaaa info:

                 cid: 03534453453136478083d92bff0107b5 
                 csd: 400e00325b59000076b27f800a404013 
                 scr: 0235840300000000 
                date: 07/2016 
                name: SE16G 
                type: SD 
preferred_erase_size: 4194304 
               fwrev: 0x0 
               hwrev: 0x8 
               oemid: 0x5344 
              manfid: 0x000003 
              serial: 0x83d92bff 
              uevent: DRIVER=mmcblk MMC_TYPE=SD MMC_NAME=SE16G MODALIAS=mmc:block 
          erase_size: 512

http://sprunge.us/VFiN

 

This barely cover UCH-I U2 specifications, for U3 there must be at least 30Mb/s write. Can you tell me if this is some board limitation, or this sd card is not real U3?

tkaiser

tkaiser

Posted
  • Author
Posted
  On 8/11/2016 at 9:30 AM, RagnerBG said:

Can you tell me if this is some board limitation, or this sd card is not real U3?

 

Board limitation. A20's SDIO implementation with mainline kernel will not exceed 23 MB/s (unfortunately true for all Allwinner based SBC currently known, maybe Olimex' upcoming A64 board will be the first exception). Random IO looks nice but compared to the best buys (currently Samsung EVO with either 32GB or 64 GB) your card is too expensive :)

 

Same with Samsung Pro or Pro+ -- specs look nice since high sequential transfer rates are guaranteed. But what a surprise, we're not using digital cameras with fast host controllers but SBCs and here

  • the host implementation limits sequential throughput anyway,
  • random IO is way more important and
  • the pretty cheap EVO (or EVO+) outperform all tested more expensive cards easily when it's about this
RagnerBG

RagnerBG

Posted
Posted
  On 8/11/2016 at 10:48 AM, tkaiser said:

 

Board limitation. A20's SDIO implementation with mainline kernel will not exceed 23 MB/s (unfortunately true for all Allwinner based SBC currently known, maybe Olimex' upcoming A64 board will be the first exception). Random IO looks nice but compared to the best buys (currently Samsung EVO with either 32GB or 64 GB) your card is too expensive :)

 

That's good to know, thank you. About the price, it's cheap - 10$ from ebay, that's why i have some doubts about the origin. Unfortunately it's appears i don't have necessary hardware to test it. My 2 card readers and my phone have something like >=20Mb/s r/w limit and this test above is the best result i see so far.

tkaiser

tkaiser

Posted
  • Author
Posted
  On 8/11/2016 at 5:44 PM, RagnerBG said:

About the price, it's cheap - 10$ from ebay, that's why i have some doubts about the origin.

 

Well, I bought 2 EVO 32 GB at a local store for 8€ each this week (faster card in most if not all SBCs with twice the capacity ;) )

 

But back to checking cards. You should use f3 to check the whole card. Since a while Armbian supports this sort of media checking (using both f3 and iozone):

cd /path/to/mountpoint
armbianmonitor -c

This does not work as root and it might take ages if you got a counterfeit card so better run it overnight. But it will check all available free space on the card and gives you a performance overview too.

overnight

overnight

Posted
Posted

Sony SR-16MX2 UHS-I Class 3 16GB, 90/60MB/S r/w nominal speed.

 

Benchmarks:

 

  Reveal hidden contents

 

 

Card info:

  Reveal hidden contents

 

 Tested on NanoPi Neo w/o heatsink.

Tido

Tido

Posted
Posted

SanDisk Extreme microSDHC UHS-I 16GB - February 2015, as it has been used quite a bit, I just ran it once

 

    Lesegeschwindigkeit: bis zu 90MB/s
    Schreibgeschwindigkeit: bis zu 40MB/s
    Videogeschwindigkeit: C10, U3

 

 

  Reveal hidden contents

 

 

@lamobo-r1:~$ sudo armbianmonitor -u
uploaded to http://sprunge.us/SiGb

hrip6

hrip6

Posted
Posted

This is my result:

 

  Reveal hidden contents

 

Card info:

  Reveal hidden contents

 

armbianmonitor -u: http://sprunge.us/hUhE

 

Too slow Micro SD Card you think :(? I'm newbie and playing with Banana Pi for a year ago but I still have some problem with it :((

  • Igor unpinned this topic
lagerschaden

lagerschaden

Posted
Posted

a Toshiba Exceria 32GB on an OrangePi One - ARMBIAN 5.37.171221 nightly Debian GNU/Linux 8 (jessie) 3.4.113-sun8i 

                                                              random    random 
              kB  reclen    write  rewrite    read    reread    read     write
          102400       4     1646     1719     7660     7658     6295      167                                                          
          102400      16     5743     5283    14291    14254    13093       37                                                          
          102400     512    11085    10968    22590    21994    20114     1146                                                          
          102400    1024    14581    14444    22596    22597    22549     2344                                                          
          102400   16384    15162    13057    22762    22763    22758    12308

and the 2. run: 

                                                              random    random
              kB  reclen    write  rewrite    read    reread    read     write
          102400       4     1883     1907     7834     7834     6543      184                                                          
          102400      16     7406     7107    13679    14571    13393       38                                                          
          102400     512    15185    15097    22614    22615    22518     1189                                                          
          102400    1024    14787    17266    22630    22632    22586     2372                                                          
          102400   16384    17930    15759    22750    22754    22753    10334

and the MMC-Info 

mmc0:1234 info:

                 cid: 02544d5341333247252735f690011683 
                 csd: 400e00325b590000e74f7f800a4000d5 
                 scr: 0235840301000000 
                date: 06/2017 
                name: SA32G 
                type: SD 
preferred_erase_size: 4194304 
               fwrev: 0x5 
               hwrev: 0x2 
               oemid: 0x544d 
              manfid: 0x000002 
              serial: 0x2735f690 
              uevent: DRIVER=mmcblk MMC_TYPE=SD MMC_NAME=SA32G MODALIAS=mmc:block 
          erase_size: 512

P1030658.JPG

Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept