hojnikb Posted March 29, 2017 Posted March 29, 2017 @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.
hojnikb Posted March 29, 2017 Posted March 29, 2017 @tkaiser Quote his whole threads gets useless when flooded with posts! I suggest locking the thread then and just updating OP with relevant results/information
tkaiser Posted March 29, 2017 Author Posted March 29, 2017 6 minutes ago, hojnikb said: I suggest locking the thread then and just updating OP with relevant results/information It's only you constantly flooding threads with useless stuff. I finally give up now.
zador.blood.stained Posted March 29, 2017 Posted March 29, 2017 @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.
hojnikb Posted March 29, 2017 Posted March 29, 2017 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.
plasta-blaster Posted May 3, 2017 Posted May 3, 2017 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
inaciose Posted May 6, 2017 Posted May 6, 2017 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?
pzw Posted May 6, 2017 Posted May 6, 2017 Try: https://www.sandisk.com/home/memory-cards/microsd-cards/ultra-microsd Don't know where you can buy them in your country though..
kotc Posted June 7, 2017 Posted June 7, 2017 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
ttf236@126.com Posted June 21, 2017 Posted June 21, 2017 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 ?
kotc Posted July 27, 2017 Posted July 27, 2017 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
tkaiser Posted July 27, 2017 Author Posted July 27, 2017 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)
chwe Posted August 29, 2017 Posted August 29, 2017 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. H2testw looked ok (my SD-card reader on the notebook is internally connected via USB2 so forget about read performance here ). 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: 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 ) 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)
tkaiser Posted August 29, 2017 Author Posted August 29, 2017 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)
chwe Posted August 29, 2017 Posted August 29, 2017 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?
tkaiser Posted August 29, 2017 Author Posted August 29, 2017 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) 1
Moklev Posted January 10, 2018 Posted January 10, 2018 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
tkaiser Posted January 11, 2018 Author Posted January 11, 2018 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
Moklev Posted January 11, 2018 Posted January 11, 2018 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.)
tkaiser Posted January 11, 2018 Author Posted January 11, 2018 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
Moklev Posted January 11, 2018 Posted January 11, 2018 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).
tkaiser Posted February 22, 2018 Author Posted February 22, 2018 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 6
tkaiser Posted July 18, 2018 Author Posted July 18, 2018 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? 1
EndtheFED Posted August 8, 2018 Posted August 8, 2018 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
Bernie_O Posted October 17, 2018 Posted October 17, 2018 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 1
chwe Posted October 17, 2018 Posted October 17, 2018 hmm the numbers looking for me like a magnitude to high.. (at least).. Sure you didn't benchmark your SSD (even then, apple must have nice SSDs in their notebooks )? and/or there's some caching still active (but even then it looks to high for me).
TonyMac32 Posted October 18, 2018 Posted October 18, 2018 I tested a SanDisk extreme A2 (64 GB), got results matching tkaiser's.
Bernie_O Posted October 18, 2018 Posted October 18, 2018 (edited) 8 hours ago, chwe said: hmm the numbers looking for me like a magnitude to high.. (at least).. Sure you didn't benchmark your SSD (even then, apple must have nice SSDs in their notebooks )? 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 October 18, 2018 by Bernie_O
Bernie_O Posted October 18, 2018 Posted October 18, 2018 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
![m][sko](https://forum.armbian.com/uploads/n2a/n2a-180904eb9612afa23a4c3358385bd86f384613e3.avatars_letters_gd.png){kind=avatar}
Recommended Posts