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

How to script QOS to be off at night

Discussion in 'Tomato Firmware' started by dailyglen, Feb 9, 2012.

  1. dailyglen

    dailyglen Networkin' Nut Member

    Hi,

    During the night I don't want QOS on (as batch jobs are running) and I'm trying to figure out how to turn QOS off at night and back on in the morning. I thought the following script would work but it doesn't:

    Code:
    nvram set qos_enable="1"  # or 0
    sleep 2
    nvram commit
    Then I was going to put an On and Off script under Scheduler. Two questions:

    1) Anyone know how to turn QOS on/off with a script (or otherwise)?
    2) Anyone know if doing this is bad for wearing out my NVRAM? Is there a better method?

    Thanks!
     
  2. Planiwa

    Planiwa LI Guru Member

    Have you tried:
    Code:
    nvram set qos_enable=0
    service qos stop
    ...
    nvram set qos_enable=1
    service qos start
    
    Have you considered having an alternate set of rates for night-time, instead of turning QOS off entirely? That way you can maintain the benefits of QOS, with relaxed rules.

    Try this:
    Code:
    nvram export --set |grep 'qos_.rates'
    
    Then, in the two scripts, stop, set the appropriate rates, restart.

    No need to nvram commit, unless you make a change that must persist across reboots.

    All references to nvram, whether "get" or "set", "find", "show", or "export", are to the cached RAM copy. Only "commit" writes the RAM cache out to Flash, and only boot reads from the Flash. ("Erase" erases the NVRAM Flash memory, so that a subsequent boot will reflash the NVRAM from the Firmware (defaults).)

    All Tomato GUI "SAVE"s do a "commit" unless this is prevented in Administration > Debugging.

    In case you didn't know, if you change one bit in the NVRAM, and commit, the whole thing is reburned!

    At least that is my understanding.
     
  3. Toastman

    Toastman Super Moderator Staff Member Member

    You can also enter the commands in the scheduler at the appropriate times:
    service qos stop
    service qos start
     
  4. Planiwa

    Planiwa LI Guru Member

    Yes. That is necessary, but is it sufficient?

    Is "nvram set qos_enable=?" not also necessary to avoid inconsistency?

    Otherwise, it appears that parts of QOS persist. (Which may be considered a feature, although perhaps risky.) For example, it seems that the QOS connection classification chart still works.
     
  5. dailyglen

    dailyglen Networkin' Nut Member

    Hi, what Toastman said is sufficient, thanks.

    From running some tests the QOS service does not read the settings from RAM (at least for the BW limits) until it is restarted. If you have nvram set qos_enable="0" and then service qos start it effectively doesn't start QOS; however service qos stop will always stop QOS.

    Thanks.
     
  6. Planiwa

    Planiwa LI Guru Member


    Since no one has addressed my (rhetorical) question, let me state it clearly:

    Yes, doing only service qos stop ... service qos start will work, but it will leave the system in an inconsistent state for the duration. The proper way is to also set qos_enable, as I indicated.

    The following shows the problem clearly:
    Code:
    WRT: nvram find qos_e
    qos_enable=0
    WRT: uptimes
    24 Feb 12:12 init   
    24 Feb 12:12 wanup   
    24 Feb 13:47 fire   
    WRT: service qos start
    ..
    Done.
    WRT: nvram find qos_e
    qos_enable=0
    WRT: uptimes
    24 Feb 12:12 init   
    24 Feb 12:12 wanup   
    24 Feb 16:49 fire   
    WRT: ### QOS Basic Settings page shows QOS OFF ; QOS Pie charts are OFF and at the bottom it says QOS Disabled
    WRT: nvram set qos_enable=1
    WRT: ## now QOS GUIs say enabled, but pie chars are still empty (unclassified)
    WRT: uptimes         
    24 Feb 12:12 init   
    24 Feb 12:12 wanup   
    24 Feb 16:49 fire   
    WRT: service qos start
    ......
    Done.
    WRT: uptimes
    24 Feb 12:12 init   
    24 Feb 12:12 wanup   
    24 Feb 16:58 fire   
    WRT: ## note that the service command showed more dots this time
    WRT: ## and the pie charts are active
    WRT: nvram find qos_e
    qos_enable=1
    WRT: service qos stop
    ...
    Done.
    WRT: nvram find qos_e
    qos_enable=1
    WRT: ## QOS GUI pages indicate that QOS is still ON, although there is only partial functionality
    WRT: service qos start
    .....
    Done.
    WRT: ### note how many dots ;  looks like QOS is functional again.
    
     
  7. quietsy

    quietsy LI Guru Member

    If you want consistency, you will also have to do a commit so that the nvram won't lose the changes after a reboot.
     
  8. Planiwa

    Planiwa LI Guru Member

    Consistency and persistence are not the same.

    The matter that I am talking about has nothing to do with persistence across reboots. It is about whether or not what the GUI shows reflects the actual fact. If the GUI says that QOS is enabled, but it is in fact not enabled, that is a contradiction, or an inconsistency.

    Parts of the system are informed by the NVRAM image in use (in RAM). Once the system has booted, it never checks the flashed NVRAM. It only checks the NVRAM image in RAM.

    If it were otherwise, then running with the option "Avoid performing an NVRAM commit" would be pointless. This option is very useful for those who frequently make changes to NVRAM content, but do not want to reflash their entire NVRAM, unless the changes are intended to be permanent.

    I have a shell script that checks whether the NVRAM was reflashed since the last check, which I will gladly share if there is interest.
     

Share This Page