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

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):

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.

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.

Click to expand...

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.

If you read the entire thread, the issue was determined to be his own misunderstanding of how it works, brought on by very bad documentation/guides online (which should come as no surprise, most people do not understand technology correctly ).

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.

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.

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%).

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.