Date: Mon, 20 Mar 2017 09:26:44 -0600 From: Warner Losh <imp@bsdimp.com> To: Ian Lepore <ian@freebsd.org> Cc: "Dr. Rolf Jansen" <rj@obsigna.com>, "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Re: Identifying counterfeit microSD cards on a Beaglebone Black Message-ID: <CANCZdfrp9vSsZC1R%2BXWepCpfuCOQuPGgnB2Lh9=%2B4RD8EJMWuQ@mail.gmail.com> In-Reply-To: <1489962657.80839.8.camel@freebsd.org> 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> <1489962657.80839.8.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Mar 19, 2017 at 4:30 PM, Ian Lepore <ian@freebsd.org> wrote: > 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 checked about a year or so ago. I'm pretty sure it's correct for SD cards. eMMC cards only use the older commands defined for them, and so may use a less efficient form of the command. There's a related 'predelete' command for when you know you are writing more than one block that can have a large positive effect on some SD cards, but it's a APP CMD, and the current setup of that makes it hard to use where we'd need to issue it.... Some tests I did resulted in inclusive results, so I never did it right... > 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. Yes. SD cards are even worse than SSDs when it comes to the effects of TRIM. Horrible performance across a broad range of technologies suggests some heuristic to disabling it if the performance sucks. Most people don't actually have work loads that require TRIM to get the full warrantee period out of their drives. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfrp9vSsZC1R%2BXWepCpfuCOQuPGgnB2Lh9=%2B4RD8EJMWuQ>