Re: [Roll] draft-rahul-roll-rpl-observations-00 Section 2.1: Wear leveling

Hello Carsten,

Thanks for raising this.
Like you mentioned, wear leveling requires over-provisioning of flash sectors. In some scenarios, application does not (or does very limited) persistent write (for e.g. street light scenario). Thus there is very less over-provisioning assumed. In such cases, it is difficult to ask for over-provisioning just for the sake of RPL (since there is no other module doing such (relatively) frequent writes). Also RPL signaling does not allow multiple state information to be clubbed together and do a single write(write is in terms of pages and thus not good for less number of bytes). The question is, Is it possible for RPL signaling to reduce persistent write at the cost of adding some signaling during node boot (at-least for 6LRs and 6LNs). Node reboot will be relatively rare-occurrence (or at-least much less frequent) and thus the cost of additional signaling bits might be worth it (?). Also I feel new RPL extensions should consider this and do not commit to persistent storage more frequently.

Thanks,
Rahul

-----Original Message-----
From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Carsten Bormann
Sent: 22 March 2018 18:29
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Subject: [Roll] draft-rahul-roll-rpl-observations-00 Section 2.1: Wear leveling

Today, at the mike, I asked about wear leveling.

The numbers in 2.1 seem to assume you do a full erase/write cycle per store operation.
That is not a good way to use Flash storage.  Obviously, for true wear leveling you need a bit more flash space (and a bit more code, which also needs flash space), but then there already are other items that you want to commit to stable storage on a somewhat regular basis.

Grüße, Carsten

_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll