Scheduled LED Control. NVRAM commits - wear out issue?

[mmmmmm]

Hi,

I am thinking about using the amazing "Scheduled LED Control" feature offered by Merlin's version on my RT-N66U.

However, before enabling the scripts as described in the wiki, I have to ask:
- is it safe to do so many nvram commits?

I intend to switch off leds during the night and turn them on in the morning but I am afraid that these operations will wear out the NVRAM.
If this is true, is there another way to use this scheduled task?

Thank you.

 

[RMerlin]

Hi,

I am thinking about using the amazing "Scheduled LED Control" feature offered by Merlin's version on my RT-N66U.

However, before enabling the scripts as described in the wiki, I have to ask:
- is it safe to do so many nvram commits?

I intend to switch off leds during the night and turn them on in the morning but I am afraid that these operations will wear out the NVRAM.
If this is true, is there another way to use this scheduled task?

Thank you.

You could try the script without the nvram commit. It should work fine for this specific scenario (you will have to test it tho). The real problem would be if you were to change an actual router setting without doing a commit - in that case the setting might never be saved, and be back to the original value after a reboot.

Beyond that, I have no idea how many write cycles the nvram can support. Pretty sure I have done more commits by now than most of you will ever do during your router's lifetime, so I'd expect mine to go out before any of yours

 

[mmmmmm]

Pretty sure I have done more commits by now than most of you will ever do during your router's lifetime, so I'd expect mine to go out before any of yours

And we all here appreciate the huge effort you put into this and we all should contribute so you'll never have to worry about wearing out your nvram.
(I am talking about paypal donations here)

Thank you very much for taking the time to answer my questions.

 

[RMerlin]

Thank you very much for taking the time to answer my questions.

Please let me know if it works reliably for you with the commit removed. If it does, I will update the Wiki to remove the commit call from the scripts, just to be on the safe side.

 

[mmmmmm]

Hello Merlin,

just tested the scripts without the nvram commit and I confirm that it works as expected.

I suppose the only small issue will be in case of a power failure when the router will reboot without the previous setting being commited. But I don't think this is something to worry about.

Here are my scripts:
/jffs/scripts/services-start

#!/bin/sh

cru a ledsoff "0 23 * * * /tmp/mnt/sda1/myscripts/ledsoff.sh"
cru a ledson "0 7 * * * /tmp/mnt/sda1/myscripts/ledson.sh"

/tmp/mnt/sda1/myscripts/ledson.sh

#!/bin/sh

nvram set led_disable=0
service restart_leds

/tmp/mnt/sda1/myscripts/ledsoff.sh

#!/bin/sh

nvram set led_disable=1
service restart_leds

(the sda1 is a usb stick the I keep plugged in all the time)

Thank you for your help.

 

[RMerlin]

just tested the scripts without the nvram commit and I confirm that it works as expected.

I suppose the only small issue will be in case of a power failure when the router will reboot without the previous setting being commited. But I don't think this is something to worry about.

Thanks for confirming - I will update the Wiki.

Preserving the state between reboots might be nice, but probably not worth the extra wear. Someone who still wants to could still put the commit calls back if they wished so.

Note that you could put both scripts in the jffs partition if you don't need the USB disk for anything else.

 

[joegreat]

However, before enabling the scripts as described in the wiki, I have to ask:
- is it safe to do so many nvram commits?

I intend to switch off leds during the night and turn them on in the morning but I am afraid that these operations will wear out the NVRAM.
If this is true, is there another way to use this scheduled task?

Hi,

It' hard to say for what number of writhe cycles the router NVRAM is build, without the exact specifications of the NVRAM chip.

In worst case it's only build for a few thousend writes, most likely it's in the range of 100,000 writes - as most other consumer products. If it would be a high quality/heavy duty chip (e.g. MIL specs) it would be even in 1 Mio. write range.

Therefore your approach of not commiting NVRAM is by sure the best thing to do!

With kind regards
Joe