Identifying counterfeit microSD cards on a Beaglebone Black

[Dr. Rolf Jansen]

Am 23.03.2017 um 23:52 schrieb Warner Losh <imp at bsdimp.com>:
> On Thu, Mar 23, 2017 at 8:46 PM, Dr. Rolf Jansen <rj at obsigna.com> wrote:
>> Am 23.03.2017 um 17:37 schrieb Warner Losh <imp at bsdimp.com>:
>>> On Thu, Mar 23, 2017 at 8:07 AM, Ian Lepore <ian at freebsd.org> 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 <lists.br at gmail.com>:
>>>>>> On 19 March 2017 at 18:45, Dr. Rolf Jansen wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> ... 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?
>>>> 
>>>> 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 and Ian, thank you very much for sharing your much deeper insights on the matter.
>> 
>> I am setting up a prototype for a mostly autonomous measurement device for an industrial application using the BBB as the controller. For this reason I am interested in the ti_adc driver, and I was glad that I got it working.
>> 
>> Once the device has been setup, writes to the SD card will be limited to logging measurement data and activity events besides the normal FreeBSD logging. The 4 GB internal flash of the BBB would be more than sufficient to hold everything, however, I was thinking that using an external SD card in order not to damage the BBB because of flash wear, would be a good idea.
>> 
>> Well, for this kind of application $40 is still in the budget, however, it comes already close to the cost of the BBB itself. Perhaps, I simply forget the SD cards and provide to my future customers spare BBB's.
>> 
>> Anyway, I guess I need to do some lifetime simulation of the external flash compared to the internal one, so I could take a more educated decision based on these results.
> 
> Lifetime / endurance is normally normalized to 'Drive Writes Per Day'.
> You should check to see what the endurance of the eMMC in the unit is.
> You may have enough headroom to just log there. SSDs always specify
> this, but SD cards seem to rarely do.

I did a search on these figures for the BBB, although I did not found the exact value, what I read was discouraging enough for me. So I decided not to touch the internal flash too much.

Many thanks again

Rolf