4 edits |
Tomato QoS major bug (resolved - normal behavior)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, toastman) 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): Edit: fixed screenshot, 1% min. |
|
|
random
Anon
2012-Dec-29 9:43 pm
Re: Tomato QoS major bug (all versions, incl toastman, shibby)You have a case for #1.
Highest should not be 10% to 100%. The amount should be a small percentage of total upload available. It should be only the most important. e.g. VoIP. The amount is reserved EVEN when it is not being used at the moment, so it is not available for everything else. So if you take off 100kbps, then all you have left is 900kbps for everything else.
Then you work you way down the priority. I hope your numbers add up.
There are FAQ and long discussions on the official sites specifically talking about this. |
|
|
to Cloneman
the people of IRC select option #1 has the correct reason. |
|
|
to random
said by random :There are FAQ and long discussions on the official sites specifically talking about this. And all of them are wrong, including you. Here are new settings that would adhere to your requirements, and they would not work either. only 13% is reserved in this scenario, the others are maximums. |
|
Gone Premium Member join:2011-01-24 Fort Erie, ON |
Gone
Premium Member
2012-Dec-29 10:08 pm
You have your outbound limit set to 1000kbit/s. You are aware that it should only be set to 80-90% of your upstream limit, right? This means your actual upstream is 1100-1200kbit/s? That doesn't sound right. Not limiting the upstream correctly can produce results exactly like what you described.
If you're talking incoming traffic, forget about QoS. It's just not worth the time. |
|
Ped_Man join:2004-03-27 Richmond Hill, ON |
to Cloneman
Here is a nice and long tutorial on QoS using Tomato. If you don't want to waste time trying to figuring out how to set it up. Try Toastman firmware, he has a nice set of default classification for QoS. » www.linksysinfo.org/inde ··· n.28349/ |
|
|
Once again, yes for the purpose of this discussion the upload line rate is 1.2mbps. This makes out math easier here to cap it at 1000.
This is not what is at issue. And neither is that gigantic guide and many of them like it. I've gone through those guides, none of them address this issue.
As for Incoming QoS (again, not part of this discussion!), it's not a waste of time, it does work well enough in my testing, (albeit it suffers from the same problems when dealing with many classes) |
|
|
Gone Premium Member join:2011-01-24 Fort Erie, ON |
Gone
Premium Member
2012-Dec-29 10:44 pm
If your intention is to come here and call everyone wrong or act like an asshole to the people who came here to offer the help you requested you're not going to get anything from anyone.
Having said that, your mind is already obviously made up. Go bitch to the developers since you already know more than everyone else. You're not worth anyone else's effort if this is the kind of attitude you're going to demonstrate to those who have offered to help you. |
|
|
The only person I was slightly rude to was "random", since he insisted on a 'pebkac'-type statement as the first line of his reply. :^)
The developers are not to blame here. I don't think the Core QoS logic/engine has changed much throughout revisions. |
|
Gone Premium Member join:2011-01-24 Fort Erie, ON |
Gone
Premium Member
2012-Dec-29 11:06 pm
There's a lot of decent people here who would be happy to help anyone in any way they can. Keep an open mind instead of dismissing what they is the less harsh point I was trying to make. |
|
your moderator at work
hidden : hidden :
|
|
Re: Tomato QoS major bug (all versions, incl toastman, shibby)in any case, I don't think I am being unduly rude.
"all of those guides are wrong" isn't an assumption, it's a fact. There are so many contradictions and inaccuracies in those guides, from personal experience, and many other threads that I've read, they are a guideline only and not a reference. |
|
Gone Premium Member join:2011-01-24 Fort Erie, ON |
Gone
Premium Member
2012-Dec-30 12:27 am
Write your own reference guide. Problem solved. |
|
GuspazGuspaz MVM join:2001-11-05 Montreal, QC |
to Cloneman
Your preferred approach would be incorrect... If a class is set to use 1% to 70%, it really should be able to use up to 70%. That's why you use a combination of per-class limits and a global limit. If multiple classes are contending for the bandwidth, that's when the priority order goes into effect; if you have one class at 70% and one at 50%, they'll combine to hit the global limit, and at that point the higher class will get priority.
In other words, in the scenario you describe, I would not expect, nor would I want, 30% of bandwidth to be left over. |
|
|
How then do you ensure 30% of the link is always free for your high priority traffic, and all your lower priority traffic never exceed 70% of the global maximum, with various stages of relative priority for the lower classes?
Is this not possible?
To give a more tangible example,
- ensure VoIP always has maximum priority and at least 30% of the link is unused by other traffic
- give http more priority over other types of file transfers - give certain services more priority than http |
|
not @comcast.net |
not
Anon
2012-Dec-30 11:38 am
QoS is an aggregate sum calculation, which means that you cannot reserve a total sum (all rules) of more than your total bandwidth. This is because if and when all types of protocols in use at the same time, they'll fight for bandwidth just as if there was no QoS set up. The idea of QoS is to reserve a spot in line of so much width for a particular type of traffic so that it's always there. It CANNOT be used to dictate one protocol overriding the total bandwidth available to another protocol and mark it as its own because it's prioritized higher. There will be too much fighting going on at that point.
I think this is what you're running into. As long as you can think of QoS as a rate limiting reservation rather than a rate dictating override, it'll make more sense why your % reservations must add up to the total available bandwidth. Your total piechart of bandwidth never changes, all QoS does is move the separating lines around to say which protocol has what size chunk of the total bandwidth to use. Does that make better sense? |
|
1 edit |
What you're describing seems to correlate with the results I'm seeing, but I don't see how QoS can be effective when operating in this manner.
At least in my testing, I recall that even if you give a class High Priority, it won't have good enough jitter/ping for VoIP unless there is a chunk of bandwidth left over, unassigned to anything within the global maximum you've set. |
|
Cloneman 1 edit |
hrm, I'm trying a couple situations, it seems to be providing adequate results for the moment, even though all the bandwidth is being used up.
Weather or not this holds up in every situation with more complex stresses caused by many connections, remains to be seen. I would have preferred a method that leaves more bandwidth untouched, but so be it if it works. This type of setup won't work on many DSL setups I've seen, but that's for another reason... consider my issue resolved for now. |
|
GuspazGuspaz MVM join:2001-11-05 Montreal, QC |
to Cloneman
You don't need to reserve 30% for VoIP, because QoS is about more than just bandwidth limiting. It's also about prioritization.
If you've got VoIP in the highest priority bucket, and you've saturated your global limit (which means that your line itself is never saturated), then the VoIP packets are going to always get sent out first. They get to jump the queue.
This is why QoS doesn't work well on downstream. In that case, it can't set priorities on the remote side, all it can do is try to bandwidth limit things by selectively dropping or delaying packets and hoping TCP throttles the connection. And it can't do anything to limit UDP traffic, since UDP has no congestion control mechanism. |
|
|
to Cloneman
In your example if Class 1 were not in use, I would expect that class 3 (70%) take up 70% of my connection, then would expect 4 to get 29% leaving 1% for 5. This is assuming everything is saturated.
I have my minimums for VOIP and WWW set to 20% each respectively and everything else to 5%. For Max everything is set to around 80% (except WWW which is 95%, and service kept to the default 20%. I'm not really sure why service is defaulted that way). It works great. I realize it's probably not optimal but it acheives the results I'm looking for so I haven't found the need to play with it more.
But as been pointed out, what I find more important is that the most important traffic is at the top. |
|
|
Guspaz, thanks for your input, I think I understand how upstream QoS works now.
As a sidenote, I did achieve seemingly perfect downstream QoS results in the past with my 2-classes adding up to less than 100%. |
|
not @comcast.net |
not to Cloneman
Anon
2012-Dec-30 9:49 pm
to Cloneman
No, limiting jitter on a call is about not having dropped packets. Remember that VoIP has bad quality because packets don't/cannot retransmit. That's when you get jitter and bad call quality. So, in order to keep that from happening, you build up QoS so that everything is prioritized properly. I think you're finally getting it, but treat QoS no different than the subway system. It's not about increasing the amount of trains you have or speeding them up. It's about fitting the most people in the cabins in the most efficient way. If you have a ton of "fat" people, (i.e. VoIP), you fit them in first and then fill in the small empty areas with the other smaller packets which have retransmit capabilities... either they fit or they don't and if they don't, they get in the next car or the next train via a retransmit which own't affect that traffic in a negative manner aside from speed impairment... something that doesn't affect it as badly as VoIP quality drop does. |
|
1 edit |
Re: Tomato QoS major bug (resolved - normal behavior)Just had a small epiphany -
The reason I was able to get moderate QoS success on the downstream is because I was reserving bandwidth to a point where my low classes added up to less than 100%.
I guess I "projected" the same logic on the upstream (even though it's unnecessary).
Would be interesting to have downstream and upstream classes which are independent of each other, since clearly their needs and implementations are different.
Ideally (and I'd have to do more testing to confirm this) I'd want many classes on my upstream (QoS works) and only 2 high/low classes on my downstream (where QoS is more difficult to successfully achieve).
EDIT: Further testing seems to indicate that shibby (and most likely vanilla tomato) does not have a "global inbound" limit, which is why inbound QoS sucks. However, recent Toastman builds appear to have this properly implemented (and to no surprise, given how extensive that guide is) |
|
|
I have excellent success with downstream QOS using one of Toastman's latest firmwares (modification of TomatoUSB). No problems what so ever. |
|
|
said by silvercat:I have excellent success with downstream QOS using one of Toastman's latest firmwares (modification of TomatoUSB). No problems what so ever. This is what I'm seeing as well (so far). Toastman's downstream QoS has a proper global limit, whereas other implementations aren't as clever. |
|
DavesnothereChange is NOT Necessarily Progress Premium Member join:2009-06-15 Canada 2 edits |
to Cloneman
said by Cloneman:....Further testing seems to indicate that shibby (and most likely vanilla tomato) does not have a "global inbound" limit, which is why inbound QoS sucks.
However, recent Toastman builds appear to have this properly implemented (and to no surprise, given how extensive that guide is). I currently have a Shibby build in my WRT54GL, and in the credits, I believe he says that his build includes Toastman's QoS mods. So is Toastman's version better, and is there any particular build number to choose ? After trying Shibby with QoS enabled for a while last year, my QoS is currently disengaged, for other unrelated reasons, and I have (both during and since) been doing what I always did in the past - setting bandwidth limits for both up and downstream within p2p apps - and the results have been satisfactory as a rule. Interesting thread regardless. |
|
|
said by Davesnothere:I currently have a Shibby build in my WRT54GL, and in the credits, I believe he says that his build includes Toastman's QoS mods.
So is Toastman's version better, and is there any particular build number to choose ? Since January 9th, 2012, Toastman has included an IMQ based QOS ingress system (coded by "Tiomo") -- so basically, Incoming QOS. I am not sure if this is included in the Shibby builds. It seems that the Shibby builds have always included Toastman's "outgoing" QOS mods. |
|
DavesnothereChange is NOT Necessarily Progress Premium Member join:2009-06-15 Canada |
said by silvercat:Since January 9th, 2012, Toastman has included an IMQ based QOS ingress system (coded by "Tiomo") -- so basically, Incoming QOS. I am not sure if this is included in the Shibby builds. It seems that the Shibby builds have always included Toastman's "outgoing" QOS mods. Here is a screenshot of my version's 'About' page. It looks like it is from before the date you mentioned, based on the Toastman credit. |
|
|
jibby
Member
2013-Jan-2 8:46 pm
my router on toastman lists this:
"Tiomo" Features: - IMQ based QOS Ingress - Incoming Class Bandwidth pie chart Copyright (C) 2012 Tiomo
don't see that on your shibby list so maybe it's not in there? |
|