Date: Sat, 18 Mar 2017 13:07:23 -0600 From: Ian Lepore <ian@freebsd.org> To: "Dr. Rolf Jansen" <rj@obsigna.com>, freebsd-arm@freebsd.org Subject: Re: Identifying counterfeit microSD cards on a Beaglebone Black Message-ID: <1489864043.40576.219.camel@freebsd.org> In-Reply-To: <A633D336-2581-4C51-A3C9-7AFD0ABB9E9F@obsigna.com> References: <D08E6528-56E6-4229-8722-D87116B8064D@obsigna.com> <CANCZdfo97-iFg4zLxbyQhv9rPrd8eU5rN-mzDL5wz3xj6XxrsQ@mail.gmail.com> <A633D336-2581-4C51-A3C9-7AFD0ABB9E9F@obsigna.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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>: > > > > On Sat, Mar 18, 2017 at 8:44 AM, Dr. Rolf Jansen <rj@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@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@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@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@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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1489864043.40576.219.camel>