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

Using QOS - Tutorial and discussion

Discussion in 'Tomato Firmware' started by Toastman, Dec 24, 2008.

  1. sabishii

    sabishii New Member Member

    I didn't say they were better. I was providing the missing images that are listed in the forum FAQ, specifically
    that had been missing because Imageshack sucks.

    In other words, the latest QOS settings in the forum FAQ are from 2010. If there are new settings, that's fine, but I'm just digging up missing stuff.
     
  2. gffmac

    gffmac Networkin' Nut Member

    Is there a way to revert QOS settings to stock without doing a full wipe or manually entering them all again?
     
  3. koitsu

    koitsu Network Guru Member

    I cannot confirm settings for any firmware other than Toastman. Below are the commands for ARM. I'm not sure about MIPS, probably the same but better not risk it. These are commands you can use from the CLI (telnet/SSH); I would not recommend doing this from Tools -> System Commands due to all the magic quoting and madness that goes on (plus browsers wrap text and make distinguishing whitespace locations difficult):

    I believe the forum will botch this very very badly due to the quotes, spacing, and several other aspects (particularly of the syntax of the qos_orules variable), so here is the pastebin:

    http://pastebin.com/mu4Dw16F

    *** WARNING WARNING WARNING ***

    IT IS VERY IMPORTANT YOU ENSURE THE nvram set qos_orules VALUE IS RETAINED AS IS. THE VALUE SHOULD BE WRAPPED IN APOSTROPHES (NOT DOUBLE QUOTES OR "SMART" QUOTES), IS ALL ON A SINGLE LINE, IS NOT BOTCHED/SCREWED UP BY COPY/PASTING, AND DOES NOT HAVE IMPROPER WHITESPACE INJECTED INTO THE CONTENT. DOING SO CAN/WILL BREAK THINGS VERY BADLY. I SUGGEST COPYING FROM THE "RAW PASTE DATA" PART OF PASTEBIN.
    YOU HAVE BEEN WARNED.

    The source of these values comes from router/shared/defaults.c on Toastman-ARM branch. If you want something else (MIPS, ARM7, whatever), give me the exact filename of the firmware you're using and I can go look up the relevant code and do the same process.
     
    gschnasl and gffmac like this.
  4. gffmac

    gffmac Networkin' Nut Member

    Thanks koitsu, it seems PuTTY has a character limit on pasting so the full nvram set qos_orules= .. command is not entered. I'll look for an alternative.

    Maybe the command can be split into 2 or 3 segments?

    I entered the one command via the web gui, worked fine. Thanks
     
    Last edited: Mar 7, 2017
  5. koitsu

    koitsu Network Guru Member

    PuTTY has no such clipboard character limit. I take the time to test my claims/statements before making them. :)

    The command cannot be easily split into sections without risk of the shell interpreting some characters (through use of variables).
     
  6. gffmac

    gffmac Networkin' Nut Member

    I know you know what you are talking about which is why I didn't really want make the post I tried 5 times, and via another program.

    Sent from my HTC 10 using Tapatalk
     
  7. koitsu

    koitsu Network Guru Member

    Okay, I guess I'll do an alternative. I put together a simple shell script that does the work for you (so there's nothing to copy-paste), gzip'd it (to work around any potential network I/O corruption), and put it on my server. This is what you'd do from the CLI on Tomato:

    Code:
    cd /tmp
    wget http://jdc.koitsu.org/toastman_qos_reset.sh.gz
    gzip -d toastman_qos_reset.sh.gz
    chmod 755 toastman_qos_reset.sh
    ./toastman_qos_reset.sh
    
    I urge anyone/everyone to cat toastman_qos_reset.sh first so that they understand what the script is doing (it's the same as what's at pastebin, just with the hashbang line for /bin/sh added). In general I don't like putting shell script things online for people to download/blindly run, as it puts too much trust in what a person is doing. (Yes, I'm a trustworthy person and I do commits/code changes, but my point still stands)

    The script DOES NOT do nvram commit
    -- this is intentional! So, after doing the above, you can nvram show (or nvram show | grep qos_orules etc...) and make sure the settings have changed (back to defaults).

    You then can run nvram commit yourself to commit the changes to NVRAM, followed by reboot and you should be good to go.

    Hope this makes it easier for you. Please let me know if/when you've done this so I can remove the file off my server.
     
  8. Olegaas

    Olegaas New Member Member

    Hello everybody, I have Tomato Shibby and I have trouble with QoS.

    Router - ASUS RT-66U
    Version - Tomato Firmware 1.28.0000 MIPSR2-138 K26 USB AIO-64


    The trouble is: All Inbound Bandwidth Distribution at Graphs, show as default traffic class. (Default traffic class can be choosen at Basic QoS Settings). Outbound Bandwidth Distribution work correct. Also all Inbound traffic are limiting as rule of default traffic class.
    For examle - Inbound WAN 1 Max Bandwidth Limit: 10 000kbit/s, My default traffic class is P2P/Bulk, limits of P2P/Bulk are from 5 to 40%. At result all of the traffic are limited with 40% - do not depend on class.
    Detailes you can see on screenshots.
    All settings are default. I only set Static WAN IP, and DNS.
    Change IP to 192.168.0.1 and DHCP to 192.168.0.100-199
    Disable WIFI. Thats all.

    What I try to do:
    - Install last 1.28 version (was 1.26 version)
    - Reset all setting.

    This is not help at all.
    Does anybody have ideas, how to solve this trouble?[​IMG]
    [​IMG]
     
  9. cloneman

    cloneman Networkin' Nut Member

    It's hard to tell from those screenshots as all the TCP traffic is on port 443. perhaps you could try to delete rule 29 and see what happens.

    also, the real shibby version number is on the about page.
     
  10. Olegaas

    Olegaas New Member Member

    On About page version is: Tomato Firmware 1.28.0000 MIPSR2-138 K26 USB AIO-64K

    Right now I make screenshots ot Inbond traffic, and page after press on default traffic (VOIP/GAME) right now:
    [​IMG] [​IMG]
     
  11. Olegaas

    Olegaas New Member Member

    If press on "Empty" class HТТP:
    [​IMG]
     
  12. cloneman

    cloneman Networkin' Nut Member

    okay it looks like everything is going to default in inbound like you said. I don't know why it's doing that.

    I know shibby 1.38 has some QOS problems (the bandwidth calculation estimates are missing) , so it is possible that this is a another issue. All I can suggest is to try shibby 1.32 instead. (wipe nvram as well, do not try restore settings)
     
    warchieff likes this.
  13. warchieff

    warchieff New Member Member

    Can you guys write or include a script to configure in Advanced Tomato the ingress burst size such as this one:


    tc qdisc del dev $DEV ingress 2> /dev/null > /dev/null

    tc qdisc add dev $DEV handle ffff: ingress

    tc filter add dev $DEV parent ffff: protocol ip prio 50 u32 match ip src \
    192.168.1.1 police rate ${34860}kbit burst 10k drop flowid :1


    I want to drop packets that are coming in too fast, which causes TCP/IP to slow down. Because I don't want to drop traffic unnecessarily, can you write me a 'burst' size to allow this? Is this the correct script to use within AdvancedTomato? Will this script interfere with Tomato's Ingress QOS?
     
    Last edited: Jun 27, 2017
  14. cloneman

    cloneman Networkin' Nut Member

    You can probably do it via startup script or wan up script although pressing 'save' in the QoS gui could reset it.
    iirc the relevant scripts it uses are /etc/QoS and the iptables

    I've never touched this but I'd be interested as I've yet to find something that throttles steam downloads properly
     
  15. warchieff

    warchieff New Member Member

    I want Tomato to run the QOS but there are no relevant scripts or guides to configure this type of command. I've looked at the Source Code doesn't show me anything either from some web pages but they don't really show the true code.

    This is the only way to configure ingress this way I've seen, everything else only uses the classification system.

    Works on all kernels. Within the CBQ qdisc we place two Stochastic Fairness Queues that make sure that multiple bulk streams don't drown each other out.
    Downstream traffic is policed using a tc filter containing a Token Bucket Filter.
    You might improve on this script by adding 'bounded' to the line that starts with 'tc class add .. classid 1:20'. If you lowered your MTU, also lower the allot & avpkt numbers!
    #!/bin/bash
    # The Ultimate Setup For Your Internet Connection At Home
    #
    #
    # Set the following values to somewhat less than your actual download
    # and uplink speed. In kilobits
    DOWNLINK=800
    UPLINK=220
    DEV=ppp0
    # clean existing down- and uplink qdiscs, hide errors
    tc qdisc del dev $DEV root 2> /dev/null > /dev/null
    tc qdisc del dev $DEV ingress 2> /dev/null > /dev/null
    ###### uplink
    # install root CBQ
    tc qdisc add dev $DEV root handle 1: cbq avpkt 1000 bandwidth 10mbit
    # shape everything at $UPLINK speed - this prevents huge queues in your
    # DSL modem which destroy latency:
    # main class
    tc class add dev $DEV parent 1: classid 1:1 cbq rate ${UPLINK}kbit \
    allot 1500 prio 5 bounded isolated
    # high prio class 1:10:
    tc class add dev $DEV parent 1:1 classid 1:10 cbq rate ${UPLINK}kbit \
    allot 1600 prio 1 avpkt 1000
    # bulk and default class 1:20 - gets slightly less traffic,
    # and a lower priority:
    tc class add dev $DEV parent 1:1 classid 1:20 cbq rate $[9*$UPLINK/10]kbit \
    allot 1600 prio 2 avpkt 1000
    # both get Stochastic Fairness:
    tc qdisc add dev $DEV parent 1:10 handle 10: sfq perturb 10
    tc qdisc add dev $DEV parent 1:20 handle 20: sfq perturb 10
    # start filters
    # TOS Minimum Delay (ssh, NOT scp) in 1:10:
    tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 \
    match ip tos 0x10 0xff flowid 1:10
    # ICMP (ip protocol 1) in the interactive class 1:10 so we
    # can do measurements & impress our friends:
    tc filter add dev $DEV parent 1:0 protocol ip prio 11 u32 \
    match ip protocol 1 0xff flowid 1:10
    # To speed up downloads while an upload is going on, put ACK packets in
    # the interactive class:
    tc filter add dev $DEV parent 1: protocol ip prio 12 u32 \
    match ip protocol 6 0xff \
    match u8 0x05 0x0f at 0 \
    match u16 0x0000 0xffc0 at 2 \
    match u8 0x10 0xff at 33 \
    flowid 1:10
    # rest is 'non-interactive' ie 'bulk' and ends up in 1:20
    tc filter add dev $DEV parent 1: protocol ip prio 13 u32 \
    match ip dst 0.0.0.0/0 flowid 1:20
    ########## downlink #############
    # slow downloads down to somewhat less than the real speed to prevent
    # queuing at our ISP. Tune to see how high you can set it.
    # ISPs tend to have *huge* queues to make sure big downloads are fast
    #
    # attach ingress policer:
    tc qdisc add dev $DEV handle ffff: ingress
    # filter *everything* to it (0.0.0.0/0), drop everything that's
    # coming in too fast:
    tc filter add dev $DEV parent ffff: protocol ip prio 50 u32 match ip src \
    0.0.0.0/0 police rate ${DOWNLINK}kbit burst 10k drop flowid :1
    If you want this script to be run by ppp on connect, copy it to /etc/ppp/ip-up.d.
    If the last two lines give an error, update your tc tool to a newer version!

    The following script achieves all goals using the wonderful HTB queue, see the relevant chapter. Well worth patching your kernel for!
    #!/bin/bash
    # The Ultimate Setup For Your Internet Connection At Home
    #
    #
    # Set the following values to somewhat less than your actual download
    # and uplink speed. In kilobits
    DOWNLINK=800
    UPLINK=220
    DEV=ppp0
    # clean existing down- and uplink qdiscs, hide errors
    tc qdisc del dev $DEV root 2> /dev/null > /dev/null
    tc qdisc del dev $DEV ingress 2> /dev/null > /dev/null
    ###### uplink
    # install root HTB, point default traffic to 1:20:
    tc qdisc add dev $DEV root handle 1: htb default 20
    # shape everything at $UPLINK speed - this prevents huge queues in your
    # DSL modem which destroy latency:
    tc class add dev $DEV parent 1: classid 1:1 htb rate ${UPLINK}kbit burst 6k
    # high prio class 1:10:
    tc class add dev $DEV parent 1:1 classid 1:10 htb rate ${UPLINK}kbit \
    burst 6k prio 1
    # bulk & default class 1:20 - gets slightly less traffic,
    # and a lower priority:
    tc class add dev $DEV parent 1:1 classid 1:20 htb rate $[9*$UPLINK/10]kbit \
    burst 6k prio 2
    # both get Stochastic Fairness:
    tc qdisc add dev $DEV parent 1:10 handle 10: sfq perturb 10
    tc qdisc add dev $DEV parent 1:20 handle 20: sfq perturb 10
    # TOS Minimum Delay (ssh, NOT scp) in 1:10:
    tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 \
    match ip tos 0x10 0xff flowid 1:10
    # ICMP (ip protocol 1) in the interactive class 1:10 so we
    # can do measurements & impress our friends:
    tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 \
    match ip protocol 1 0xff flowid 1:10
    # To speed up downloads while an upload is going on, put ACK packets in
    # the interactive class:
    tc filter add dev $DEV parent 1: protocol ip prio 10 u32 \
    match ip protocol 6 0xff \
    match u8 0x05 0x0f at 0 \
    match u16 0x0000 0xffc0 at 2 \
    match u8 0x10 0xff at 33 \
    flowid 1:10
    # rest is 'non-interactive' ie 'bulk' and ends up in 1:20

    ########## downlink #############
    # slow downloads down to somewhat less than the real speed to prevent
    # queuing at our ISP. Tune to see how high you can set it.
    # ISPs tend to have *huge* queues to make sure big downloads are fast
    #
    # attach ingress policer:
    tc qdisc add dev $DEV handle ffff: ingress
    # filter *everything* to it (0.0.0.0/0), drop everything that's
    # coming in too fast:
    tc filter add dev $DEV parent ffff: protocol ip prio 50 u32 match ip src \
    0.0.0.0/0 police rate ${DOWNLINK}kbit burst 10k drop flowid :1
    If you want this script to be run by ppp on connect, copy it to /etc/ppp/ip-up.d.
    If the last two lines give an error, update your tc tool to a newer version!
     
  16. cloneman

    cloneman Networkin' Nut Member

    the following command I used
    tc class change dev imq0 parent 1:1 classid 1:100 htb rate 4250kbit ceil 42000kbit cburst 3kb prio 10 quantum 1492

    temporarily changes the burst value for the ceiling. (classid 1:100 represents inbound class 9 in my case) FWIW it doesn't help with my steam problem.

    I'm not sure exactly what your goal is with regard to problematic bursting traffic. The default QoS engine should be sufficient to manage most situations. Can you describe your problematic traffic, maybe modifying the builtin QoS isn't required after all ?
     
    Last edited: Jun 28, 2017
  17. warchieff

    warchieff New Member Member

    I just want to clean up the ingress for gaming. I only have 2 classes.

    1st class - Highest. Classes 2,3,4,5,6,8,9 and 10 are empty. Class 7 is default. 80% - 80%, 20% - 20% for the two classes.

    I just want to limit the burst to small packets of 1514 KB. Even 128 KB if it would fit better. That way everything gets dropped which isn't a game packet.

    So i'd write it like this to modify all ingress?

    Highest Class
    tc class change dev imq0 parent 1:1 classid 1:100(Highest class 1 here not 9) htb rate 50000kbit ceil 47500kbit cburst 128kb prio 10(want priority 0 for gaming here) quantum 576

    Or do I also include this to modify the default class separately from the Highest ingress?

    default class
    tc class change dev imq0 parent 1:1 classid 1:100(default class 7 here not 9) htb rate 50000kbit ceil 47500kbit cburst 128kb prio 10(want priority default for all else) quantum 576
     
    Last edited: Jun 28, 2017
  18. cloneman

    cloneman Networkin' Nut Member

    I don't think you'll gain much benefit by messing with burst or cburst. You're probably in over your head trying to reverse engineer this.

    Tomato's GUI doesn't support classifying by packet size (unfortunately. That's a feature request of mine). I played with this concept in cli a few posts back http://www.linksysinfo.org/index.ph...rial-and-discussion.28349/page-12#post-265865.

    I'm not sure how you intent to classify and separate gaming traffic from normal traffic. My advice would be to move to a 3 or 4 class system -

    Class 1 (Gaming)
    Class 2 (Normal - Default)
    Class 3 (Large Downloads)


    The objective is to put your large downloads (e.g. 3000kb+) Below Normal, just in case some important traffic ends up in normal by mistake.

    If you run into issues where there really is a problem with bursty traffic (e.g. torrents and Steam Downloads in "Normal") well, then you have investigate more "invasive" limits, like a 4th bulk class for "problem traffic".

    As a last resort, anything that you limit to 50% of your connection should not cause any problems for your high priority traffic.

    If Steam downloads are causing you problems I'd recommend trying to switch to a region that is further from you. (>50ms). Having a steam CDN with a very low latency causes problems for ingress shaping.
     
    gempotpot likes this.
  19. warchieff

    warchieff New Member Member

    Yes we want to mark egress packets(check box to accelerate game packets)
    'UDP_LENGTH=256'

    Also limit the size of the ingress burst.(check box to help bursty ingress)
     
    Last edited: Jun 28, 2017
  20. mindwolf

    mindwolf New Member Member

    Any way to change the packet limit and quantum to 1000p and quantum 600? It appears editing the /etc/qos file doesn't save any changes.
     
  21. cloneman

    cloneman Networkin' Nut Member

    you can use s commad like tc class change
     

Share This Page