Identifying counterfeit microSD cards on a Beaglebone Black

Sun Mar 19 00:30:50 UTC 2017

Am 18.03.2017 um 16:07 schrieb Ian Lepore <ian at 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 at bsdimp.com>:
>>> 
>>> On Sat, Mar 18, 2017 at 8:44 AM, Dr. Rolf Jansen <rj at obsigna.com>
>>> wrote:
>>>> 
>>>> I bought a 16 GB microSDHC SanDisk chip rated at 4 MB/s write
>>>> speed for use with my Beaglebone Black.
>>>> 
>>>> 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).
>>>> 
>>>> 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.
>>>> 
>>>> Also, it would be nice to see some speed values as a reference
>>>> for microSDHC card write speeds on:
>>>> 
>>>>    FreeBSD 12.0-CURRENT (BEAGLEBONE) #0 r315413
>>>> 
>>>> 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.
>>> 
>>> 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'
>>> 
>>> 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.
>>> 
>>> 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.
>> 
>> 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.
>> 
>> 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?
>> 
>> Many thanks and best regards
>> 
>> Rolf
> 
> 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...
> 
>  root at bb:~ # dd if=/dev/random of=/dev/mmcsd0s2 bs=1m count=100
>  100+0 records in
>  100+0 records out
>  104857600 bytes transferred in 14.559020 secs (7202243 bytes/sec)
> 
> It comes in at 7mb/sec, but were we really measuring card performance?
> 
>  root at bb:~ # dd if=/dev/random of=/dev/null bs=1m count=100
>  100+0 records in
>  100+0 records out
>  104857600 bytes transferred in 6.888693 secs (15221698 bytes/sec)
> 
> 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.
> 
> So let's take the random generation cpu cycles out of the picture by
> caching some random data...
> 
>  root at bb:~ # dd if=/dev/random of=/tmp/rand bs=1m count=100
>  100+0 records in
>  100+0 records out
>  104857600 bytes transferred in 8.566184 secs (12240876 bytes/sec)
>  root at bb:~ # dd if=/tmp/rand of=/dev/null bs=1m
>  100+0 records in
>  100+0 records out
>  104857600 bytes transferred in 0.625300 secs (167691590 bytes/sec)
> 
> 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...
> 
>  root at bb:~ # dd if=/tmp/rand of=/dev/mmcsd0s2 bs=1m
>  100+0 records in
>  100+0 records out
>  104857600 bytes transferred in 7.777464 secs (13482236 bytes/sec)
> 
> 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.
> 
> Now using that command to get actual numbers for some cards I have
> laying around:
> 
>  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
> 
> 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.
> 
> 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