Identifying counterfeit microSD cards on a Beaglebone Black

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Identifying counterfeit microSD cards on a Beaglebone Black

Dr. Rolf Jansen-2
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.

Best regards

Rolf
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Identifying counterfeit microSD cards on a Beaglebone Black

Warner Losh
On Sat, Mar 18, 2017 at 8:44 AM, Dr. Rolf Jansen <[hidden email]> 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
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Identifying counterfeit microSD cards on a Beaglebone Black

Dr. Rolf Jansen-2
Am 18.03.2017 um 12:30 schrieb Warner Losh <[hidden email]>:

> On Sat, Mar 18, 2017 at 8:44 AM, Dr. Rolf Jansen <[hidden email]> 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

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Identifying counterfeit microSD cards on a Beaglebone Black

Ian Lepore-3
On Sat, 2017-03-18 at 15:03 -0300, Dr. Rolf Jansen wrote:

> Am 18.03.2017 um 12:30 schrieb Warner Losh <[hidden email]>:
> >
> > On Sat, Mar 18, 2017 at 8:44 AM, Dr. Rolf Jansen <[hidden email]>
> > 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

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Identifying counterfeit microSD cards on a Beaglebone Black

Dr. Rolf Jansen-2
Am 18.03.2017 um 16:07 schrieb Ian Lepore <[hidden email]>:

> On Sat, 2017-03-18 at 15:03 -0300, Dr. Rolf Jansen wrote:
>> Am 18.03.2017 um 12:30 schrieb Warner Losh <[hidden email]>:
>>>
>>> On Sat, Mar 18, 2017 at 8:44 AM, Dr. Rolf Jansen <[hidden email]>
>>> 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.

Best regards

Rolf
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Identifying counterfeit microSD cards on a Beaglebone Black

Dr. Rolf Jansen-2
Am 18.03.2017 um 21:30 schrieb Dr. Rolf Jansen <[hidden email]>:

> Am 18.03.2017 um 16:07 schrieb Ian Lepore <[hidden email]>:
>> On Sat, 2017-03-18 at 15:03 -0300, Dr. Rolf Jansen wrote:
>>> Am 18.03.2017 um 12:30 schrieb Warner Losh <[hidden email]>:
>>>>
>>>> On Sat, Mar 18, 2017 at 8:44 AM, Dr. Rolf Jansen <[hidden email]>
>>>> 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
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Identifying counterfeit microSD cards on a Beaglebone Black

Ian Lepore-3
On Sun, 2017-03-19 at 18:45 -0300, Dr. Rolf Jansen wrote:

> Am 18.03.2017 um 21:30 schrieb Dr. Rolf Jansen <[hidden email]>:
> >
> > Am 18.03.2017 um 16:07 schrieb Ian Lepore <[hidden email]>:
> > >
> > > On Sat, 2017-03-18 at 15:03 -0300, Dr. Rolf Jansen wrote:
> > > >
> > > > Am 18.03.2017 um 12:30 schrieb Warner Losh <[hidden email]>:
> > > > >
> > > > >
> > > > > 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 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.

-- Ian
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Identifying counterfeit microSD cards on a Beaglebone Black

Warner Losh
On Sun, Mar 19, 2017 at 4:30 PM, Ian Lepore <[hidden email]> 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 <[hidden email]>:
>> >
>> > Am 18.03.2017 um 16:07 schrieb Ian Lepore <[hidden email]>:
>> > >
>> > > On Sat, 2017-03-18 at 15:03 -0300, Dr. Rolf Jansen wrote:
>> > > >
>> > > > Am 18.03.2017 um 12:30 schrieb Warner Losh <[hidden email]>:
>> > > > >
>> > > > >
>> > > > > 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
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Identifying counterfeit microSD cards on a Beaglebone Black

Luiz Otavio O Souza-4
In reply to this post by Dr. Rolf Jansen-2
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-endurance-microsd

This same email says that running any kind of OS in any of the other
card models automatically breaks the warranty.

HTH,
Luiz
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Identifying counterfeit microSD cards on a Beaglebone Black

Dr. Rolf Jansen-2
Am 21.03.2017 um 13:25 schrieb Luiz Otavio O Souza <[hidden email]>:

> 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-endurance-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
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Identifying counterfeit microSD cards on a Beaglebone Black

Ian Lepore-3
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 <[hidden email]
> 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).

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.)

-- Ian

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Identifying counterfeit microSD cards on a Beaglebone Black

Warner Losh
On Thu, Mar 23, 2017 at 8:07 AM, Ian Lepore <[hidden email]> 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 <[hidden email]
>> 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...
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Identifying counterfeit microSD cards on a Beaglebone Black

Dr. Rolf Jansen-2
Am 23.03.2017 um 17:37 schrieb Warner Losh <[hidden email]>:

> On Thu, Mar 23, 2017 at 8:07 AM, Ian Lepore <[hidden email]> 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 <[hidden email]>:
>>>> 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.
 
Best regards

Rolf

 
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Identifying counterfeit microSD cards on a Beaglebone Black

Warner Losh
On Thu, Mar 23, 2017 at 8:46 PM, Dr. Rolf Jansen <[hidden email]> wrote:

> Am 23.03.2017 um 17:37 schrieb Warner Losh <[hidden email]>:
>> On Thu, Mar 23, 2017 at 8:07 AM, Ian Lepore <[hidden email]> 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 <[hidden email]>:
>>>>> 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.

Warner
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Identifying counterfeit microSD cards on a Beaglebone Black

Dr. Rolf Jansen-2
Am 23.03.2017 um 23:52 schrieb Warner Losh <[hidden email]>:

> On Thu, Mar 23, 2017 at 8:46 PM, Dr. Rolf Jansen <[hidden email]> wrote:
>> Am 23.03.2017 um 17:37 schrieb Warner Losh <[hidden email]>:
>>> On Thu, Mar 23, 2017 at 8:07 AM, Ian Lepore <[hidden email]> 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 <[hidden email]>:
>>>>>> 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
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"