Identifying counterfeit microSD cards on a Beaglebone Black

Sun Mar 19 21:45:20 UTC 2017

Am 18.03.2017 um 21:30 schrieb Dr. Rolf Jansen <rj at obsigna.com>:
> 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.

I found another (old) microSD card SanDisk 16 GB Class 10. After partitioning but before formatting with newfs, I tested the sequential writing speed be dd'ing directly to the device. I set apart only 50 MB in my tmpfs, and therefore I ran the tests with 40 MB (everything is run on FreeBSD 12.0-CURRENT (BEAGLEBONE) #0 r315413 mounted from the internal flash):

  # dd if=/dev/random of=/tmp/random.bin bs=1m count=40
  # dd if=/tmp/random.bin of=/dev/mmcsd1s2 bs=1m count=40

The initial results were promising, namely rates in the range from 12 to 14 MB/s.

After formatting using: ...

  # newfs -ntUE -L SYSTEM /dev/mmcsd1s2a
  # mount -o noatime /dev/ufs/SYSTEM /mnt

... the results were eventually disappointing:

  # dd if=/tmp/random.bin of=/mnt/random1.bin bs=1m count=40
  11565980 bytes/sec

  # dd if=/tmp/random.bin of=/mnt/random2.bin bs=1m count=40
   8267796 bytes/sec

  # dd if=/tmp/random.bin of=/mnt/random3.bin bs=1m count=40
    615993 bytes/sec

In contrast to writing to the mounted root filesystem / on the internal flash:

  # dd if=/tmp/random.bin of=/random1.bin bs=1m count=40
  10798380 bytes/sec

  # dd if=/tmp/random.bin of=/random2.bin bs=1m count=40
  10510983 bytes/sec

  # dd if=/tmp/random.bin of=/random3.bin bs=1m count=40
  10740969 bytes/sec

Might it be, that FreeBSD 12 treats the UFS on the internal flash somehow different compared to UFS on the microSD? Perhaps trim works on the internal flash but not on mounted SD cards?

Anyway, I will buy a new card and we'll see whether this changes something.

Best regards

Rolf