Date: Sun, 19 Mar 2017 16:30:57 -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: <1489962657.80839.8.camel@freebsd.org> In-Reply-To: <2F7D5F42-E50A-4761-9EEC-DC873BD7D0AB@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> <2F7D5F42-E50A-4761-9EEC-DC873BD7D0AB@obsigna.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 2017-03-19 at 18:45 -0300, Dr. Rolf Jansen wrote: > 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>: > > > > > > > > > > > > > > > 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, 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 I had a quick try of the same thing with a samsung and a kingston card and couldn't replicate your results. It might be interesting for you to try again but leave off the -t when formatting the filesystem. The implementation of BIO_DELETE/trim for sdcard is particularly bad in freebsd (I'm not even sure it's correct, but if it's wrong it's in a harmless way, not a data-destroying way). I've been meaning to investigate it further, just haven't found time yet. I do know that different sdcards react to delete/trim operations in different ways. Good fast cards seem to do the delete just by manipulating metadata and the operation is almost instant. Other cards do the lengthy flash-erase operations "while you wait" which usually ruins performance rather than enhancing it. -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1489962657.80839.8.camel>