Michael S (already5chosen.delete@this.yahoo.com) on August 3, 2022 6:04 am wrote:
> David Hess (davidwhess.delete@this.gmail.com) on August 3, 2022 3:48 am wrote:
> > Doug S (foo.delete@this.bar.bar) on August 1, 2022 8:37 am wrote:
> > > anon2 (anon.delete@this.anon.com) on July 31, 2022 10:55 pm wrote:
> > > > The hard problem for NAND is random read latency.
> > >
> > > Can you expand on that further? What makes random reads a problem for NAND? True they
> > > aren't as fast as sequential but hardly seem to be an issue for modern SSDs.
> >
> > The problem is that every random read requires loading an entire block, or perhaps a large
> > fraction of a block, of 2048+64 or 4096+128 bytes and executing ECC before the data becomes
> > available. That makes for a latency on the order of 50 microseconds or longer.
> >
>
> Why should it be that slow? Why not 5-10 usec?
> Besides, do you know that the coding is use (4096+128)B or you are guessing?
> My impression is that manufacturers do not publish that sort of information.
> The exception to that are codes used with SLC NAND flash devices - those are sometimes published.
> But those are very simple codes that should not take more than 1-3 usec to calculate.
>
> For modern dense TLC, I actually expect order of 200 parity bytes per 4KB block and
> error correction scheme based on either turbo-codes or LDPC. But that's just a guess.

The data is not hard to find online. Last time I looked page sizes were 2048+64, but TLC pages sizes now are 16,384+2208 bytes. A variety of clever ECC schemes are used including variable width with more ECC applied as a page ages.