Date: Sun, 19 Mar 2017 18:45:10 -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: <2F7D5F42-E50A-4761-9EEC-DC873BD7D0AB@obsigna.com> In-Reply-To: <16B03E70-00E6-4C17-9A9A-8601F4C07364@obsigna.com> 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> <16B03E70-00E6-4C17-9A9A-8601F4C07364@obsigna.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Am 18.03.2017 um 21:30 schrieb Dr. Rolf Jansen <rj@obsigna.com>:
> 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.
>=20
> 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.
>=20
> 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=3D/dev/random of=3D/tmp/random.bin bs=3D1m count=3D40
# dd if=3D/tmp/random.bin of=3D/dev/mmcsd1s2 bs=3D1m count=3D40
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=3D/tmp/random.bin of=3D/mnt/random1.bin bs=3D1m count=3D40
11565980 bytes/sec
# dd if=3D/tmp/random.bin of=3D/mnt/random2.bin bs=3D1m count=3D40
8267796 bytes/sec
# dd if=3D/tmp/random.bin of=3D/mnt/random3.bin bs=3D1m count=3D40
615993 bytes/sec
In contrast to writing to the mounted root filesystem / on the internal =
flash:
# dd if=3D/tmp/random.bin of=3D/random1.bin bs=3D1m count=3D40
10798380 bytes/sec
# dd if=3D/tmp/random.bin of=3D/random2.bin bs=3D1m count=3D40
10510983 bytes/sec
# dd if=3D/tmp/random.bin of=3D/random3.bin bs=3D1m count=3D40
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2F7D5F42-E50A-4761-9EEC-DC873BD7D0AB>