From owner-freebsd-arm@freebsd.org Sun Mar 19 00:30:49 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E72B3D086D4 for ; Sun, 19 Mar 2017 00:30:49 +0000 (UTC) (envelope-from rj@obsigna.com) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 851C3155B for ; Sun, 19 Mar 2017 00:30:49 +0000 (UTC) (envelope-from rj@obsigna.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1489883447; l=6691; s=domk; d=obsigna.com; h=To:References:Content-Transfer-Encoding:Date:In-Reply-To:From: Subject:Mime-Version:Content-Type; bh=hH3zZ838uijtay2W+6m8aIckD5KQsxXJl0HwegnJQtk=; b=h+wTEhfd5q+hi8QR94KXnq5deo9mP4BXLoo/ZvVLImiO/rCYoIoG6PhtCbCloTGM6f 4Wr+TS6/py51Opp85D0W9k7lTrBcSBR2TlBxsCuvQXbOqjRrOYDoctDsraegOoB0MbEM Ls3//SFNK/dw2EHg5KD1qfYEDpLSeUvvc8/mE= X-RZG-AUTH: :O2kGeEG7b/pS1EK7WHa0hxqKZr4lnx6UhT0M0o35iAdWtoM07Gt3wQHFGh0n99Hk6LY= X-RZG-CLASS-ID: mo00 Received: from mail.obsigna.com (bb02b8ae.virtua.com.br [187.2.184.174]) by smtp.strato.de (RZmta 40.3 DYNA|AUTH) with ESMTPSA id 40bc89t2J0UkCA2 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate) for ; Sun, 19 Mar 2017 01:30:46 +0100 (CET) Received: from rolf.projectworld.net (rolf.projectworld.net [192.168.222.15]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.obsigna.com (Postfix) with ESMTPSA id 4D9247506DAD for ; Sat, 18 Mar 2017 21:30:43 -0300 (BRT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Identifying counterfeit microSD cards on a Beaglebone Black From: "Dr. Rolf Jansen" In-Reply-To: <1489864043.40576.219.camel@freebsd.org> Date: Sat, 18 Mar 2017 21:30:41 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <16B03E70-00E6-4C17-9A9A-8601F4C07364@obsigna.com> References: <1489864043.40576.219.camel@freebsd.org> To: freebsd-arm@freebsd.org X-Mailer: Apple Mail (2.1878.6) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Mar 2017 00:30:50 -0000 Am 18.03.2017 um 16:07 schrieb Ian Lepore : > On Sat, 2017-03-18 at 15:03 -0300, Dr. Rolf Jansen wrote: >> Am 18.03.2017 um 12:30 schrieb Warner Losh : >>>=20 >>> On Sat, Mar 18, 2017 at 8:44 AM, Dr. Rolf Jansen >>> 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. 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. Best regards Rolf=