O Canada! > Canadian > Canadian Broadband > Tomato QoS major bug (resolved - normal behavior)

Tomato QoS major bug (resolved - normal behavior)

Re: Tomato QoS major bug (all versions, incl toastman, shibby)

reply to Cloneman
the people of IRC select option #1 has the correct reason.

reply to random

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.

reply 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/index.php?th···n.28349/

reply to Cloneman
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)

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.

reply to Cloneman
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.

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.

reply to Cloneman

Re: Tomato QoS major bug (all versions, incl toastman, shibby)

Write your own reference guide. Problem solved.

reply 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.
--
Developer: Tomato/MLPPP, Linux/MLPPP, etc »fixppp.org

reply to Cloneman
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

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?

reply to Cloneman
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.

reply to Cloneman
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.

reply 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.
--
Developer: Tomato/MLPPP, Linux/MLPPP, etc »fixppp.org