dslreports logo
site
 
    All Forums Hot Topics Gallery
spc

spacer




how-to block ads


Search Topic:
uniqs
5488
share rss forum feed

Cloneman

join:2002-08-29
Montreal
kudos:4
Reviews:
·TekSavvy DSL
·Bell Fibe

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

@teksavvy.com

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.


80289148

join:2012-12-24
reply to Cloneman

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


Cloneman

join:2002-08-29
Montreal
kudos:4
Reviews:
·TekSavvy DSL
·Bell Fibe
reply 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
join:2011-01-24
Fort Erie, ON
kudos:4

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
Markham, ON
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/


Cloneman

join:2002-08-29
Montreal
kudos:4
Reviews:
·TekSavvy DSL
·Bell Fibe
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)



Gone
Premium
join:2011-01-24
Fort Erie, ON
kudos:4

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.


Cloneman

join:2002-08-29
Montreal
kudos:4
Reviews:
·TekSavvy DSL
·Bell Fibe
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.



Gone
Premium
join:2011-01-24
Fort Erie, ON
kudos:4

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.

Expand your moderator at work

Cloneman

join:2002-08-29
Montreal
kudos:4
Reviews:
·TekSavvy DSL
·Bell Fibe
reply to Cloneman

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
join:2011-01-24
Fort Erie, ON
kudos:4

Write your own reference guide. Problem solved.



Guspaz
Guspaz
Premium,MVM
join:2001-11-05
Montreal, QC
kudos:23
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


Cloneman

join:2002-08-29
Montreal
kudos:4
Reviews:
·TekSavvy DSL
·Bell Fibe
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



not

@comcast.net

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?


Cloneman

join:2002-08-29
Montreal
kudos:4
Reviews:
·TekSavvy DSL
·Bell Fibe

1 edit
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.


Cloneman

join:2002-08-29
Montreal
kudos:4
Reviews:
·TekSavvy DSL
·Bell Fibe

1 edit
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.



Guspaz
Guspaz
Premium,MVM
join:2001-11-05
Montreal, QC
kudos:23
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


graniterock
Premium
join:2003-03-14
London, ON
Reviews:
·WIND Mobile
·TekSavvy Cable
reply 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.


Cloneman

join:2002-08-29
Montreal
kudos:4
reply to Cloneman

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


Cloneman

join:2002-08-29
Montreal
kudos:4
Reviews:
·TekSavvy DSL
·Bell Fibe

1 edit
reply to Cloneman

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)



silvercat

join:2007-11-07

I have excellent success with downstream QOS using one of Toastman's latest firmwares (modification of TomatoUSB). No problems what so ever.


Cloneman

join:2002-08-29
Montreal
kudos:4
Reviews:
·TekSavvy DSL
·Bell Fibe

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.


Davesnothere
No-BHELL-ity DOES have its Advantages
Premium
join:2009-06-15
START Today!
kudos:7

2 edits
reply 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.


silvercat

join:2007-11-07
Reviews:
·Start Communicat..

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.


Davesnothere
No-BHELL-ity DOES have its Advantages
Premium
join:2009-06-15
START Today!
kudos:7

Click for full size
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

join:2008-03-31

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?