Date: Sat, 18 Mar 2017 21:30:41 -0300 From: "Dr. Rolf Jansen" <rj@obsigna.com> To: freebsd-arm@freebsd.org Subject: Re: Identifying counterfeit microSD cards on a Beaglebone Black Message-ID: <16B03E70-00E6-4C17-9A9A-8601F4C07364@obsigna.com> In-Reply-To: <1489864043.40576.219.camel@freebsd.org> References: <D08E6528-56E6-4229-8722-D87116B8064D@obsigna.com> <CANCZdfo97-iFg4zLxbyQhv9rPrd8eU5rN-mzDL5wz3xj6XxrsQ@mail.gmail.com> <A633D336-2581-4C51-A3C9-7AFD0ABB9E9F@obsigna.com> <1489864043.40576.219.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Am 18.03.2017 um 16:07 schrieb Ian Lepore <ian@freebsd.org>: > On Sat, 2017-03-18 at 15:03 -0300, Dr. Rolf Jansen wrote: >> Am 18.03.2017 um 12:30 schrieb Warner Losh <imp@bsdimp.com>: >>>=20 >>> On Sat, Mar 18, 2017 at 8:44 AM, Dr. Rolf Jansen <rj@obsigna.com> >>> wrote: >>>>=20 >>>> I bought a 16 GB microSDHC SanDisk chip rated at 4 MB/s write >>>> speed for use with my Beaglebone Black. >>>>=20 >>>> The internal flash offers practical write speeds in the range of >>>> 2 to 3 MB/s when copying data to it from a NFSv4 volume depending >>>> on the size of the files being copied. Executing the same copy >>>> operation with said microSDHC card as the target I see only 0.1 >>>> to 0.2 MB/s (less than 1/10). >>>>=20 >>>> I suspect now that I got a counterfeited card. Before I dump it, >>>> I would like to run a definitive non-destructive test, preferably >>>> on the Beaglebone Black, and I would like to ask you for >>>> suggestions. >>>>=20 >>>> Also, it would be nice to see some speed values as a reference >>>> for microSDHC card write speeds on: >>>>=20 >>>> FreeBSD 12.0-CURRENT (BEAGLEBONE) #0 r315413 >>>>=20 >>>> Many thanks in advance for any help. >>> Copy a huge file from /dev/zero. Smaller files in the filesystem >>> generate a lot of overhead and 'wait points' that slow down overall >>> performance. >>>=20 >>> Or better yet, dd to the raw device. /dev/random should generate >>> data >>> faster than the card can handle. Depends on what you mean by >>> 'non-destructive' >>>=20 >>> And all NAND sucks. It's a pig with lipstick on it. So you won't >>> get >>> even performance if the FTL in the SD card sucks. Garbage >>> collection, >>> internal house keeping, etc all can steal performance from the user >>> application. These cards are generally designed to take a burst of >>> writes when the camera or video is taken, then have it read back >>> later. A mixed workload was never optimized for on most of these >>> cards, so it can also significantly degrade performance even at low >>> percentage mixtures. >>>=20 >>> So all those things could be going on w/o it being a counterfeit. >>> :(. >>> Of course, it could have all those things going on and also be a >>> counterfeit. Hard to say for sure unless the performance is wildly >>> different. But 4MB/s write performance is pretty pathetic for a >>> card >>> of that size, so it's on the low end, which suffers most from >>> uneven >>> performance and "down hill with the wind" spec numbers. >> Warner, thank you very much for taking your time responding. >>=20 >> It is a Class 4 card, i.e. guaranteed minimum write speed should be 4 >> MB/s, and I know the difference between advertised and practical >> speed, I would have expected at lest 50 % of the advertised speed, >> i.e. something in the range that can be achieved with the internal >> flash of the BBB. I would even be happy if it would come close to 1 >> MB/s. But 0.1 MB/s that is a quit huge difference -- 40 times less >> than the advertised speed. >>=20 >> You said, that 4 MB/s is "pretty pathetic". Therefore let me ask a >> different question. What is the best write speed that can be achieved >> with what model of a microSD card on a Beaglebone Black running >> FreeBSD 12-Current? >>=20 >> Many thanks and best regards >>=20 >> Rolf >=20 > First we've got to keep in mind that BBB has a wimpy processor, and = the > sdhci driver for beaglebone uses PIO, not DMA. If we try a naive test > of writing 100mb of random data to the sdcard... >=20 > root@bb:~ # dd if=3D/dev/random of=3D/dev/mmcsd0s2 bs=3D1m count=3D100 > 100+0 records in > 100+0 records out > 104857600 bytes transferred in 14.559020 secs (7202243 bytes/sec) >=20 > It comes in at 7mb/sec, but were we really measuring card performance? >=20 > root@bb:~ # dd if=3D/dev/random of=3D/dev/null bs=3D1m count=3D100 > 100+0 records in > 100+0 records out > 104857600 bytes transferred in 6.888693 secs (15221698 bytes/sec) >=20 > So ~15mb/sec just generating and writing random numbers to /dev/null, > that's not very good, in theory an sdcard can write faster than that. >=20 > So let's take the random generation cpu cycles out of the picture by > caching some random data... >=20 > root@bb:~ # dd if=3D/dev/random of=3D/tmp/rand bs=3D1m count=3D100 > 100+0 records in > 100+0 records out > 104857600 bytes transferred in 8.566184 secs (12240876 bytes/sec) > root@bb:~ # dd if=3D/tmp/rand of=3D/dev/null bs=3D1m > 100+0 records in > 100+0 records out > 104857600 bytes transferred in 0.625300 secs (167691590 bytes/sec) >=20 > That's more like it, now we're not measuring processor performance = when > we use dd. Now let's see what a raw write to that same sdcard does > using the cached random data... >=20 > root@bb:~ # dd if=3D/tmp/rand of=3D/dev/mmcsd0s2 bs=3D1m > 100+0 records in > 100+0 records out > 104857600 bytes transferred in 7.777464 secs (13482236 bytes/sec) >=20 > So that's about twice as fast as our first naive attempt to test > writing 100mb of random data, and probably represents something pretty > close to the actual BBB raw write speed under best-case conditions for > an sdcard: large sequential writes. >=20 > Now using that command to get actual numbers for some cards I have > laying around: >=20 > Apacer 8gb class 10: 14226229 bytes/sec (industrial temp range) > Kingston 8gb class 4: 7008571 bytes/sec > Kingston 8gb class 10: 9715391 bytes/sec > Lexar 8gb class 6: 8821627 bytes/sec > Sandisk 2gb class n/a: 6163704 bytes/sec (predates speed classes) > Samsung 32gb class 6: 13482236 bytes/sec >=20 > So the cards that perform best are the two I have which cost more than > twice as much as any of the others. Not surprising, I suppose. >=20 > Remember all of these 'dd' tests are for an sdcard's best-case > condition. Real-world UFS accesses are anything but best-case. The > thing an sdcard is worst at is small writes (anything from single- > sector to 16k is very small compared to the typical 4mb erase-block > size on a modern sdcard). Writing ufs metadata is lots and lots of > small writes. You can reduce the writes quite a bit by using > softupdates without journaling. Ian, many thanks for your research. The maximum write speed that I could = achieve was 1 MByte/s with dd'ing cached random data, and the test = results varied quite a bit when repeating the same dd command, the worst = speed was 500 kByte/s. I will buy a new card, and hopefully I will come with that one more = close to the range of rates that you reported for your various cards. Best regards Rolf=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?16B03E70-00E6-4C17-9A9A-8601F4C07364>