1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Weekend rant: Avoid NVRAM Commit

Discussion in 'Tomato Firmware' started by sarelc, Jan 20, 2013.

  1. sarelc

    sarelc Addicted to LI Member

    TL;DR: [ Feature Request: Warn before wiping uncommitted settings ]

    Having used Tomato for a few years now, I can say with certainty that in the future I'll avoid selecting any consumer router that can't run it. And I'm sure a lot of people here are in the same boat. It's been great to watch the firmware progress, being passed along from dev to dev, gaining features and leaving old problems behind.

    One of the many headaches Tomato users are spared when setting up their routers is that unlike the stock firmwares of SMC, D-Link, and many others, Tomato does not reboot each and every time you save a setting. It's a ridiculous practice and would not be necessary if these manufacturers ensured a minimal level of quality in their code. There is a vaguely related feature in Tomato that has always irked me however, and I thought I'd take a few minutes to complain about it. ;)

    What I'm referring to is the "Avoid NVRAM Commit" switch. This little guy has been around as long as I can remember, and (partially) true to its name, it stops Tomato from writing to the router's non-volatile memory every time you change a setting. The common reason for using this, is it makes it easy to remove problem settings. If a change you make breaks something or crashes the router, you can easily reboot it to revert to a working configuration. Another effect the function has is decreasing the wear and tear on the NVRAM. Writes to the router's flash memory most commonly occur during setup, whether it's the first time, after changing firmware versions, or after some sort of problem. With ~50 settings pages in a large distribution like Shibby's AIO these writes can quickly add up, even assuming you get everything right the first time. While not all that important for average consumers who will set the router up once, change its wireless key a few times, and then throw it in the trash 8 months later when they can't remember the admin password, it is a nice idea for those of us who will re-purpose, re-configure, and re-flash the thing until it just doesn't work any more.

    So, what's my problem with this feature? Well, it's the name - it doesn't really match its function. Avoiding something implies that the something in question is still done at some point. "Disable NVRAM Commit"? Sure. "Require Manual NVRAM Commit"? Great! But "Avoid"? Nope, that's just not accurate.

    Where this comes into play for me is on a new install. I enable the "Avoid..." feature right away so I can consolidate my changes and write them all at once. And I get about 80% of the way through the process, only to hit one of those few pages that does make Tomato reboot. This, of course, wipes everything out, and I have to start over. This isn't a common issue by any means, but it is kind of nasty, and it definately leaves me feeling bitter - and I'm just not used to that with Tomato!

    There are several ways this could be improved upon. The most direct would be changing the name of the feature, but this wouldn't actually increase the functionality. Almost as easy, would be to display a warning on the pages that make Tomato reboot - but having it visible all the time would be detrimental to the relatively clean and minimal aesthetics. Some code could be written to display the warning only when the feature is enabled, but in my mind that same code would be better used as follows. Instead of warnings, an ideal way of solvling this would be to change the function of the "Save" button on the offending pages. If the "Avoid NVRAM Commit" feature is enabled, rather than "saving" and immediately rebooting (which does the same thing as only rebooting), the user could be presented with the following dialog box:
     
  2. mstombs

    mstombs Network Guru Member

    I think its called "avoid" because not all commits can be blocked, so you can also have the problem of unwanted things getting written while 'experimenting'.

    I agree a prompt if a web gui user command requires a reboot - but don't you want option to continue without saving?
     
  3. Planiwa

    Planiwa LI Guru Member

    Perhaps this is a matter of good design, usability, and language skills?

    There are many who want to add this or that feature to Tomato. But none that I am aware of who have any interest in perfecting the essence.

    For example:

    "some services will be restarted"
    so many nasty surprises
    why not

    1. list the services that will be restarted
    2. give that information *before* the user commits

    and yes, give options, about "NVRAM commit", keeping last choice as default.






    But the way this forum works -- it favours opining, but not collaboration.

    I wanted to participate in the conversation of improving the QOS pie charts, but I gave up after the primary author made it impossible to to so without opening an account somewhere and either paying "premium" money or using nonstandard encodings and installing software to decode them!

    But those choices too, are design choices, which have consequences.


    The dream of collaboration rarely comes true.

    At best, people report errors and developers fix them.
    Or people request random features and developers graft them on top of whatever there is.

    But how often does anyone say "we've been building and building, isn't time we start designing"?

    But design is hard, and good design is very rare.
     
  4. Planiwa

    Planiwa LI Guru Member

    Perhaps a UI principle might be:
    "warn of unexpected side-effects"
    "confirm before taking drastic action"
    "do not program unnecessary, undesirable, drastic side-effects".​

    Of course this involves judgement.

    For example, when assigning a static IP address to a device,
    a side-effect is the loss of IP-traffic data for all devices,
    because the firewall is restarted, which resets the counters.

    Is this expectable? Is it necessary? Could it be circumvented?

    Related to this: When converting an associated wireless device to static,
    the administrator typically wants this to take effect immediately,
    without affecting any other device or losing any accumulated data.

    Now, even if the lease is terminated, the client remains associated,
    and there is no effective way for the administrator to disassociate it.

    Mysteriously, though, the old dynamic IP address remains
    and clutter-pollutes the IP-traffic reporting space.

    Thus, reasonably-expected desirable effects do not happen,
    while unexpected undesirable effects do.
     
  5. sarelc

    sarelc Addicted to LI Member

    Thanks for the interesting replies.

    I have never noticed this, can you give an example of where it occurs?

    Not particularily. Since this dialog would only appear if Avoid NVRAM Commits is enabled, "continue without saving" means losing all your changes - which would be very confusing since the button you pressed was named "Save":
    You could still offer the choice as in the above example, but "No" is the same as clicking "Reboot" from any page. Additionally, asking for two decisions (save? reboot?) with one question is not very popular with inexperienced users.

    DD-WRT does have its "Save" vs. "Apply" buttons, though I seem to recall their meanings is almost the reverse of what I expected (in that "Apply" means "Save and reboot", rather than "Apply without saving").


    @Planiwa:
    And that's a shame. The UI's functionality is very nice, but the level of intuitiveness could definitely stand to be improved. Another example is the inconsistent "Please wait"-type screens.

    I've never used a build with IP-Traffic before, is this behaviour different than the Bandwidth function?

    Agreed. Many of the actual HTML controls have tooltip balloons to show required formatting or (mostly) why entries are invalid - but I can't think of any that explain what the options DO. Having just tried Shibby's build I did enjoy that some pages have notes at the bottom, even if some of the info conflicts with what little documentation can be found elsewhere. It's a start, anyway.
     

Share This Page