By: anon2 (anon.delete@this.anon.com), November 26, 2022 2:00 am
Room: Moderated Discussions
Heikki Kultala (heikki.kultala.delete@this.gmail.com) on November 25, 2022 11:48 pm wrote:
> anon2 (anon.delete@this.anon.com) on November 25, 2022 4:07 pm wrote:
> > Heikki Kultala (heikki.kultala.delete@this.gmail.com) on November 25, 2022 7:31 am wrote:
> > > The ECC needs to be stored. as ones ane zeroes
> >
> > ECC can be stored out of band. Flash controllers can disable on chip ECC and do their own.
> >
> > Then, depending on the translation layer, ECC adjustments could be written independently,
> > e.g., streamed out to the log. If you had a frequently updated page, you could keep the ECC
> > in a cache even, and only write it out on power failure or when the page is filled.
> >
> > I don't know of if anybody is actually doing that (multi programming the NAND) or if it would
> > be very useful or even possible. Programming a modern NAND is a fine art and there are all
> > sorts of effects from every operation (read, program, erase) including on nearby devices.
>
> Storing the ECC to totally separate place as the data is horribly inefficient.
>
> Two reads to totally separate places is considerably more expensive than one slightly wider read.
Yeah that is true.
>
> And storing the ECC bits to somewhere else does not solve the actual problem - they still have to
> be erased. If storing them to different kind of flash memory that has much smaller erase blocks -
> then that memory is MUCH more expensive per bit than the memory used to store the actual data.
>
> Making everything much bigger, more expensive, slower and more power-hungry.
No that's not the case, log structured devices can present a logical layer that is essentially random access, and if you have the right hardware (e.g., a small page fill buffer that can persist the last unwritten page of data if there is a power failure) then the program/erase side does not matter.
>
> That something is theoretically possible and that something makes sense are totally different things.
But you're still right about data requiring two reads being inefficient.
> anon2 (anon.delete@this.anon.com) on November 25, 2022 4:07 pm wrote:
> > Heikki Kultala (heikki.kultala.delete@this.gmail.com) on November 25, 2022 7:31 am wrote:
> > > The ECC needs to be stored. as ones ane zeroes
> >
> > ECC can be stored out of band. Flash controllers can disable on chip ECC and do their own.
> >
> > Then, depending on the translation layer, ECC adjustments could be written independently,
> > e.g., streamed out to the log. If you had a frequently updated page, you could keep the ECC
> > in a cache even, and only write it out on power failure or when the page is filled.
> >
> > I don't know of if anybody is actually doing that (multi programming the NAND) or if it would
> > be very useful or even possible. Programming a modern NAND is a fine art and there are all
> > sorts of effects from every operation (read, program, erase) including on nearby devices.
>
> Storing the ECC to totally separate place as the data is horribly inefficient.
>
> Two reads to totally separate places is considerably more expensive than one slightly wider read.
Yeah that is true.
>
> And storing the ECC bits to somewhere else does not solve the actual problem - they still have to
> be erased. If storing them to different kind of flash memory that has much smaller erase blocks -
> then that memory is MUCH more expensive per bit than the memory used to store the actual data.
>
> Making everything much bigger, more expensive, slower and more power-hungry.
No that's not the case, log structured devices can present a logical layer that is essentially random access, and if you have the right hardware (e.g., a small page fill buffer that can persist the last unwritten page of data if there is a power failure) then the program/erase side does not matter.
>
> That something is theoretically possible and that something makes sense are totally different things.
But you're still right about data requiring two reads being inefficient.
Topic | Posted By | Date |
---|---|---|
Is 1 more expensive than 0? | Andrey | 2022/11/21 05:23 AM |
Is 1 more expensive than 0? | Juha Lainema | 2022/11/21 06:15 AM |
Is 1 more expensive than 0? | Adrian | 2022/11/21 07:21 AM |
Is 1 more expensive than 0? | anon2 | 2022/11/21 05:29 PM |
switching between 0 and 1 is what consumes power | Heikki Kultala | 2022/11/21 07:23 AM |
Thank you all for your answers. (NT) | Andrey | 2022/11/21 08:29 AM |
Is 1 more expensive than 0? | Foyle | 2022/11/21 08:58 AM |
Is 1 more expensive than 0? | Michael S | 2022/11/21 10:51 AM |
Is 1 more expensive than 0? | Captain Obvious | 2022/11/21 11:29 AM |
obvious stuff | anonymou5 | 2022/11/21 02:25 PM |
obvious stuff | Andrey | 2022/11/21 02:50 PM |
obvious stuff | Michael S | 2022/11/21 03:43 PM |
SRAM is bistable | Anon | 2022/11/21 10:50 AM |
SRAM is bistable | Andrew Clough | 2022/11/22 05:53 AM |
NAND Flash 1 and 0 | jokerman | 2022/11/24 01:13 PM |
NAND Flash 1 and 0 | Joern Engel | 2022/11/25 12:00 AM |
NAND Flash 1 and 0 | Ungo | 2022/11/25 02:26 AM |
The ECC needs to be stored. as ones ane zeroes (NT) | Heikki Kultala | 2022/11/25 08:31 AM |
The ECC needs to be stored. as ones ane zeroes | anon2 | 2022/11/25 05:07 PM |
The ECC needs to be stored. as ones ane zeroes | Heikki Kultala | 2022/11/26 12:48 AM |
The ECC needs to be stored. as ones ane zeroes | anon2 | 2022/11/26 02:00 AM |