[Yaffs] bit error rates]

[William Watson]

Continuing the thread about bit error rates...

In some stress testing on a prototype about a year ago, we detected about
one soft error every day or two.  (We were using an early private license
YAFFS2, with 256 MB Samsung 2kB page NAND chips, if I recall correctly.)  We
had a low-level test program running.  It wrote one page, read the entire
NAND, wrote another page, read the entire NAND, etc., as the only task, and
therefore at about the maximum data throughput of which our system was
capable, about 1 or 2 MB/second.  A quick calculation: we have 86400 seconds
per day, so we had about 100 GB/day of data read, and perhaps 1 MB/day of
data written.  We found this of concern, but not alarming, as our typical
usage pattern on a rugged hand-held with a commercial OS would be MUCH
lower.  I don't recall that we identified read disturb or write disturb as
the culprit.

As far as I can recall (and as far as the engineer who did the testing can
recall), we did NOT see two errors on any one page.  That is, each error
that we saw happened on a different page, and did NOT seem to indicate that
we had merely discovered a weak page.

The best option appeared to be to force a garbage collection of the data in
that block and erase the block.  Block retirement seemed more appropriate in
cases where a write failed (indicating that a write operation did not
correctly change 1s to 0s on a page write), where an erase failed (the chip
could not restore 0s to 1s), or where a verification of the data written
failed.  This approach would match the recommendations from Toshiba.


New thought: perhaps YAFFS could use two distinct ways of marking a block
bad, one for cases where it detected an ECC error and another for cases
where a write operation failed.  If these were distinct from the
manufacturer's initial bad block marking, one coould determine which effect
caused which proportion of bad blocks in the system.


I will also note that a NAND vendor who paid us a visit at about that same
time said that we should expect WORSE soft error behaviour with succeeding
generations of NAND flash chips.  The geometries would get smaller and
smaller, the chip dies would get larger and larger, and the amount of time
for production testing of each chip would not increase, or at least, not
increase as fast as the total storage of a chip.  Thus, the testing per page
would only go down in subsequent generations of chips.  These two statements
seemed to say that we would see both (1) increased rates of ECC errors, and
(2) an increase in the number of marginal blocks not marked bad by the chip
vendor.


As an aside, it seems to me that the ECC strategy used by YAFFS2 at present
is inefficient in the use of check bits.  It provides SEC-DED (Single Error
Correction - Double Error Detection) within each 256 byte portion of a 2kB
page, independent of the other portions of a page, at a cost of roughly 24
bytes of check data (3 check bytes per 256 data bytes).  Unfortunately, I am
not enough of a mathematician to be able to devise an ECC scheme with double
bit correction.  Do we have any such person on this list?  Perhaps this has
all moved off into the MTD, wirth which I am completely unfamiliar.  The
present ECC scheme also may work well with existing hardware support, which
a new scheme would not be able to use.


Another obvious alternative strategy for preventing data loss due to
accumulation of multiple bit errors would be to periodically read the entire
data array, checking for ECC errors.  You'd want to calculate the impact
that such reading would have on the rate of appearance of errors, as well as
the impact on system and NAND performance.  For a standard file system, it
might suffice to perform one additional data chunk read for every N read
requests, incrementing the "scrub" page each time.  This would ensure a
complete read scrub at a fixed percentage overhead.  One could also perform
a read scrub every M write operations, if desired.

Regards,

William

--
wjw1961 at gmail.com
William J. Watson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.aleph1.co.uk/pipermail/yaffs/attachments/20060215/aabbfcab/attachment.htm