From owner-freebsd-arm@freebsd.org Sun Mar 19 21:45:20 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 71E6ED139EB for ; Sun, 19 Mar 2017 21:45:20 +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::11]) (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 0C04439D for ; Sun, 19 Mar 2017 21:45:19 +0000 (UTC) (envelope-from rj@obsigna.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1489959915; l=8597; s=domk; d=obsigna.com; h=To:References:Content-Transfer-Encoding:Date:In-Reply-To:From: Subject:Mime-Version:Content-Type; bh=hooPLhMF3IDSj6Ns3YYVNtB6dU47eDK2w7dEQ/6X0Ek=; b=SANLOtEU6uxZhi8VQH2FEWG0BXikcNg7EsKfB1ohoozhFEdZMbMAhEAHP8NnTW1TBy 1YCr1zawBOb/WqHUMX1Fx3mWIAExOasg3dkBkNXwPeS5zZAI45nHjRz2IMx9lyIa6Ej9 qiHLR30iQIhMRhMs2Abk6Yl5Krndhts9mptxU= 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.1 DYNA|AUTH) with ESMTPSA id L0a42dt2JLjEKYK (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 22:45:14 +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 EEC727506DAD for ; Sun, 19 Mar 2017 18:45:11 -0300 (BRT) Content-Type: text/plain; charset=us-ascii 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: <16B03E70-00E6-4C17-9A9A-8601F4C07364@obsigna.com> Date: Sun, 19 Mar 2017 18:45:10 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <2F7D5F42-E50A-4761-9EEC-DC873BD7D0AB@obsigna.com> References: <1489864043.40576.219.camel@freebsd.org> <16B03E70-00E6-4C17-9A9A-8601F4C07364@obsigna.com> 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 21:45:20 -0000 Am 18.03.2017 um 21:30 schrieb Dr. Rolf Jansen : > 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. >=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