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

Tomato QoS question (all versions, incl toastman, shibby)

Discussion in 'Tomato Firmware' started by cloneman, Dec 30, 2012.

  1. cloneman

    cloneman Networkin' Nut Member

    Reposting - since this seems to be a more appropriate forum.

    It's been awhile since I bothered dealing with it, but I've repeated it with different people and different Tomato versions (stock, mlppp, shibby)

    Either
    1) I'm ignorant on how QoS is "supposed" to work
    - or-
    2) It's not designed correctly.

    My problem is very specific:

    Situation:
    You assign 3 upstream classes, one at 50% max, another 60% max, and a third one at 70% max. You apply stress to each one of these classes.

    You'd expect to have 30% bandwidth left over. and no congestion for a 4th class.

    But that's not how it works at all. It sums them all up and tries to use 50+60+70 = 180%, so theres nothing left over - for anything.

    Let me be clear - this is not a thread about various general QoS pitfalls. QoS works for me, if I the sum of my classes never exceeds the total bandwith. (for example, 75% everything else, 20% voip reserved, will never exceed 100%)

    This workaround is not ideal because there's only 2 classes to work with.

    I challenge anyone who says "tomato QoS works for me" to prove me wrong on this. Stress various classes at once, and there's nothing left for your high priority traffic.

    For those of us who are more visual, an example setup that would generate this problem (assume 1.2mbit connection available):

    [​IMG]
     
  2. Porter

    Porter LI Guru Member

    A preliminary note: If you want to use QoS, please use a recent Toastman build. You didn't say which one you were using. I'm just saying this to avoid any confusion.

    Why are you under the impression that nothing is left over? It's about priorities which means that if your Highest class still has traffic to send, it gets to send its traffic, no matter how much other traffic the lower priority classes have. There is an exception to this rule: the left value resembles the guarenteed rates. So if your Highest class could send 100%, it still only gets to send 99% if your class 4 has traffic to send (the 1%).

    You don't have to leave room for other traffic, the QoS-system does this for you by following the rules you gave it.

    Sorry, but I can't find a bigger issue here. If you think I didn't understand what you were saying, please tell me what you want to achieve with your QoS-setup.
     
  3. digiblur

    digiblur Networkin' Nut Member

    There's not supposed to be anything left. When something with a higher priority starts room is made. That's the point of QOS.

    -- "Sensorly or it didn't happen!"
     
  4. cloneman

    cloneman Networkin' Nut Member

    Is that supposed to be enough? I have no faith that a tiny VoIP connection will get the latency/jitter it wants when the entire pool is used up, even if it's set to higher priority
     
  5. cloneman

    cloneman Networkin' Nut Member

    The issue is resolved for now - QoS rules appear to work nonetheless even though the entirety of the global limit is consumed when stressing multiple classes.

    I would have preferred to be able to set aside more bandwidth, but if the setup works I won't complain.
     
  6. koitsu

    koitsu Network Guru Member

  7. cloneman

    cloneman Networkin' Nut Member

    The purpose of this thread from the beginning, was to determine weather I had found a bug or if this was normal behavior.

    This thread will be helpful to others in the future, considering that in many hours of troubleshooting QoS, I've never come across a guide that clearly explains that maximums were not absolute for all classes combined, but that doesn't matter, QoS is smart enough to prioritize even when there's mixed stress and seemingly all the bandwidth is being used.
     
  8. Toastman

    Toastman Super Moderator Staff Member Member

    One request from moderator - in future, please research / ask questions to determine if your assumptions are correct before posting with a title like "Major Bug" as misinformation of this kind is detrimental to the whole project.

    Thanks

    Have a good 2013.
     
  9. cloneman

    cloneman Networkin' Nut Member

    Sorry :/ The problem was I couldn't edit the title on this board once I'd realized I was mistaken for upstream QoS.

    I still think the downstream implementation on shibby (and possibly others) isn't particularly effective(toastman works). Shibby for one doesn't have a global maximum on the download side of things.

    since I have your attention, I'm wondering if you've ever encountered an issue where you have to assign a very low upload "maximum" on certain aDSL connections. My DSL has an upload payload rate of 700kbps (about 830kbps minus PPPoE losses), but I get problems unless I give up A LOT of bandwidth (max up must be set to 400kbps or lower)

    Depending on which DSL modem I use, assigning an upstream max greater than 400 will cause increased jitter (2wire or SS5360) or packet loss (Speedtouch 516 or TP-link 8816 modems).

    As a general rule, I have problems with jitter or loss if I use up 60% of the download and upload capacity at the same time (even with QoS turned off)

    For instance, if I'm using
    10mbit out of 16mbits, (Download)
    and
    450 out of 700 kbps (Upload)

    My dsl modem doesn't like this no matter what I do, and begins dropping packets (VoIP testing).
    No packets are dropped if only upload or only download is being stressed (up to 90%).

    I haven't had the chance to test this on cable or VDSL yet.
     
  10. Porter

    Porter LI Guru Member

    You are right, if you want a QoS-system that actually works, use Toastman. Shibby didn't include the new patches.

    The problem you are describing is most likely caused by ATM overhead, which only occurs on ADSL-connections (not VDSL). This problem is most obvious when using VoIP over the connection. tvlz patched Toastman's firmware with the atm-patches which enables the kernel to calculate this overhead correctly, meaning your QoS will still work and you won't have to limit your upload speed to 60% of the actual rate. Provided that you know the right overhead values, which can be a bit tricky. Here is the post by tvlz: http://linksysinfo.org/index.php?threads/speedmod-with-tc-atm-qos-patch-for-adsl.31541/#post-209915

    Maybe there is a build for your router available. I've been using the build for a WRT54GL and it works nicely.

    Please keep in mind that not every ISP provides you with the same bandwidth over the course of a day. If your bandwidth is fluctuating you have another problem at your hands.
     
  11. cloneman

    cloneman Networkin' Nut Member

    Thank you, Porter, very enlightening. I knew I wasn't crazy :^)

    I'll be looking into it some more. I have a WRT54GL, neatgear 3500L v1 and Linksys E4200 v1 to test with
     

Share This Page