From owner-freebsd-arm@freebsd.org Thu Mar 23 20:37:59 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 6A1A3CA1CC7 for ; Thu, 23 Mar 2017 20:37:59 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 391791E26 for ; Thu, 23 Mar 2017 20:37:59 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x229.google.com with SMTP id f84so5158572ioj.0 for ; Thu, 23 Mar 2017 13:37:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=IqoxKjp/kNmlQSHJcgQ0JzQ1a5ZNcYrtRsgBatCsYkg=; b=i6ZgB6M1GKWQWntY9+JQJqqwc56yoymmcjqxwsCfEUGKsvaCILCCRBjS7bmc9FWUx0 hw4ni8MXkTt2ciATYX2kvBR6Ur9eq+gT4iHUQmGjQxY+YCiP2x3F0k49sH9K+fhXzrte ysKGSy9PBOcr9VydzxUfVMxFQCfkYdV27uGv6gU6wzC828f685L5WNI6v9yInmJ5rmP5 U1XrjimKDYhB6UtMD260sw4BSpAW9bSbFWAGuUssgaFH1xaQYFwR8RGTkFMih0vJK/cc +ZEDShPN54DXUfWu2Rt2XTUzvojD0AWGimyNZneLTLS6e89Ju3TppPPAjNrBK7HXHoIO tOhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=IqoxKjp/kNmlQSHJcgQ0JzQ1a5ZNcYrtRsgBatCsYkg=; b=BU00N1wY0hOTp6vySxWtXx6Wz1lv433LJnvn90USoFJchEM8qBbnyV71pNqznl/XmS d83wjmQNxoQbngJ+GkXSMQC2lRCYNHiLZyUlcAaRrK+G+soB7erE1bCfHxQckwfnhdYj k0Ha0Vk85Kfr/XFQiUeYnXs5YmoWbD92j1nEHvUb5N7kY9+8iNEtgb/N55wuC878XgK+ Mxt4qYDV5z72QeyJUGg69wm0cwArIcFNp6H/39kT5HPeJK8eqNpDGDvC5+Bz+X8mFoY8 R+o0zVkcbqruYtt3AEyUdzBPZGW/EZsBIb23Gie9hWvLmPffSftBlExlNLFjEiPUFsEp MCMA== X-Gm-Message-State: AFeK/H2lbsAVOu6YX7ErbEDz2klJQ2iMb11qkVh1F3mNFiSWRJcsJyZOgx9wEyVDyFIxCA/KFiza2e1WVSMYJA== X-Received: by 10.107.198.193 with SMTP id w184mr4814758iof.19.1490301478377; Thu, 23 Mar 2017 13:37:58 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.146.24 with HTTP; Thu, 23 Mar 2017 13:37:57 -0700 (PDT) X-Originating-IP: [50.253.99.174] In-Reply-To: <1490281652.58015.71.camel@freebsd.org> References: <1489864043.40576.219.camel@freebsd.org> <16B03E70-00E6-4C17-9A9A-8601F4C07364@obsigna.com> <2F7D5F42-E50A-4761-9EEC-DC873BD7D0AB@obsigna.com> <70C95FC9-4B0A-4DA4-9857-EFAF41522D1B@obsigna.com> <1490281652.58015.71.camel@freebsd.org> From: Warner Losh Date: Thu, 23 Mar 2017 13:37:57 -0700 X-Google-Sender-Auth: nmS9MdsLt27J_EVKGAHGUXCRElI Message-ID: Subject: Re: Identifying counterfeit microSD cards on a Beaglebone Black To: Ian Lepore Cc: "Dr. Rolf Jansen" , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 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: Thu, 23 Mar 2017 20:37:59 -0000 On Thu, Mar 23, 2017 at 8:07 AM, Ian Lepore wrote: > On Thu, 2017-03-23 at 00:42 -0300, Dr. Rolf Jansen wrote: >> Am 21.03.2017 um 13:25 schrieb Luiz Otavio O Souza > m>: >> > >> > On 19 March 2017 at 18:45, Dr. Rolf Jansen wrote: >> > > >> > > 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: >> > > > > > > >> > > > > > > >> > > > > > > On Sat, Mar 18, 2017 at 8:44 AM, Dr. Rolf Jansen >> > > > > > > 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. >> > [picking a random message to reply] >> > >> > I just saw an email from SanDisk support (whatever this means) >> > where >> > they claim the only supported model for this kind of use is the >> > high-endurance series: >> > https://www.sandisk.com/home/memory-cards/microsd-cards/high-endura >> > nce-microsd >> > >> > This same email says that running any kind of OS in any of the >> > other >> > card models automatically breaks the warranty. >> Luiz, thank you very much for the note. Do you know, whether this >> high endurance XC card is compatible with the Beaglebone Black? >> >> Best regards >> >> Rolf > > I would assume that it is, they're typically just standard sd cards > with flash arrays based on SLC technology and with a lot of extra space > for reassigning bad blocks (a card that claims 8gb capacity could > actually have 4x that many blocks or more available internally). I don't think there's 4x over-provisioning. Where do you get that figure? When I was at Fusion I/O, the designs there were all in the 9-24% range, and our "intel" on what others were doing showed a range of 5% to 40% depending on the market segment and type of NAND use. If they are really using SLC NAND for these cards, the sparing is likely less because TLC NAND has about a 200-300 endurance rating (program erase cycles per erase block). MLC is between 3000-5000. SLC is like 30,000-100,000. SLC has also 10-100x better error rates than MLC which has 10-100x better than TLC due to how the charge nodes are programmed and the tolerances associated with that programming. There was constant pressure to come up with designs that needed less sparing, so I doubt things have changed to require 4x over provisioning.... What might be going on when people say that has to due with a feature of modern NAND chips: they can be programmed as SLC, MLC or TLC often on a per-erase block basis. In that case, a SLC configuration with a 33% over provisioning would have a 4x maximum theoretical raw capacity over the selected size for the drive (so a 8GB drive would have 8GB * 1.33 (over provisioning: spares and OOB) * 3 (TLC multiplier) or 32GB of raw capacity). > But be aware that high-endurance or industrial-rated cards can be very > expensive. I think at work we pay around $40 each for industrial-rated > 8gb cards. (One of them was included in those test results I posted, > and the performance was among the best, at least you get something for > all that extra money.) Part of the issue is that NAND chips these days can be SLC, MLC or TLC depending on how you program them (often on an erase-block level).[*] This means that the 8GB SLC card could also be a 16GB MLC card or a 24GB TLC card (well, due to sparing it likely wouldn't scale linearly). So from that perspective, I can see where a 4x number might come up (high number of bits possible for the die vs capacity configured for SLC + spares). At 33% sparing, the differences between the SD presented capacity point of 8GB would have close to 32GB of potential raw capacity were it run in TLC mode.... In addition, high endurance cards are often selected from the wafers at manufacturing time because they have the lowest error rate and other metrics so the NAND makers know that they will survive (the NAND manufacturing process isn't too uniform across the wafer due to micro variations in the wafer and other effects at the nano-scale). Often times these are also pulled from processes that typically yield better results but are more expensive. So the relative rarity of the raw dies plus the increased production cost plus running them in a faster, more reliable mode all lead to the cards being more expensive.... So that's why it's so expensive, especially on the high end: you are paying extra for quality. Warner [*] At least before 3d NAND, which I've not see as detailed a technical spec for. They likely do it as well, but I haven't seen the detailed datasheets for those like I have for generations prior...