Topic 'Tomato QoS major bug (resolved - normal behavior)' in forum 'Canadian Broadband' - dslreports.com

Re: Tomato QoS major bug (resolved - normal behavior)

Sat, 26 Jan 2013 03:59:51 EDT

mikefxu posted :

yup you found it ;)

Toastman is merging TC-ATM patch with his code now, I think the latest version has it.

Use tc-atm setting (40bytes for me) for adsl/adsl2+ connections.

Cable and vdsl should not need this setting.

40-PPPoE LLC/Snap. I came to the same conclusion after picking through the settings/configuration on the modem.

I am still having problems getting it dialed in. Can you provide some screenshots of your current QoS setup? I have the newest version of Shibby build and it does have the "global maximum" for inbound QoS.

Edit: cloneman provided in other thread: »Re: Cloneman's Tomato QoS Tips for adsl, vdsl2, and cable

Re: Tomato QoS major bug (resolved - normal behavior)

Sat, 26 Jan 2013 03:25:57 EDT

Cloneman posted : yup you found it ;)

Toastman is merging TC-ATM patch with his code now, I think the latest version has it.

Use tc-atm setting (40bytes for me) for adsl/adsl2+ connections.

Cable and vdsl should not need this setting.

Re: Tomato QoS major bug (resolved - normal behavior)

Sat, 26 Jan 2013 02:41:42 EDT

mikefxu posted :

said by Cloneman:

I've done some testing with the special TC-ATM patch builds which attempt to fix the ATM overhead QoS problem on ADSL.

I'll be creating a new thread shortly to explain this. Basically, with ADSL, small packets like VoIP packets get 'lost' because QoS doesn't account for ATM overhead properly. The patch takes care of that.

Without the patch,you have to take 50% of the upload off the table as your maximum - not an ideal solution. The patch fixes this for me.

The experimental patch is available here:
»www.box.com/s/45a87641237557490213

If you're using Cable or VDSL, regular toastman builds are fine.

Has this thread been created yet? I have a Motorola 3347 and to the best of my searching it is a ADSL modem.

Edit: Is this it? »Cloneman's Tomato QoS Tips for adsl, vdsl2, and cable

Re: Tomato QoS major bug (resolved - normal behavior)

Fri, 04 Jan 2013 14:24:18 EDT

Cloneman posted : I've done some testing with the special TC-ATM patch builds which attempt to fix the ATM overhead QoS problem on ADSL.

I'll be creating a new thread shortly to explain this. Basically, with ADSL, small packets like VoIP packets get 'lost' because QoS doesn't account for ATM overhead properly. The patch takes care of that.

Without the patch,you have to take 50% of the upload off the table as your maximum - not an ideal solution. The patch fixes this for me.

The experimental patch is available here:
»www.box.com/s/45a87641237557490213

If you're using Cable or VDSL, regular toastman builds are fine.

Re: Tomato QoS major bug (resolved - normal behavior)

Fri, 04 Jan 2013 01:16:15 EDT

Davesnothere posted :

said by silvercat:

said by Davesnothere:

Which version of Toastman are each of you using, and will it work on Cisco/Linksys WRT54GL router ?

....it looks like the best firmware (and most updated one) for your WRT54GL router would be from the ND branch (2.4 kernel):
tomato-WRT54G_WRT54GLUSB-1.28.7633.3-Toastman-IPT-ND-VPN....

Thanks, folks. :)

Just over 24 hours ago, I had looked around and reached the same conclusion - tomato-WRT54G_WRT54GLUSB-1.28.7633.3-Toastman-IPT-ND-xxx series (BTW, there seem to be 6 flavours even of THAT one), though had not yet read the specific notes on it.

My current Shibby 1.28 series build is based on the 2.4 kernel too.

The 4shared site wanted me to register to get anything, so I tried the MediaFire site »www.mediafire.com/?88t1vzzcgrphx (both sites were suggested by the author »www.linksysinfo.org/index.php?th···s.36106/ ), and it showed me all of the .BINs, including that series, (not sure that 4shared did that) and it needed no login.

BACK STORY :

My original reason for researching Tomato was that I was considering MLPPP with my (then) 5M/800K DSL, so I went out and bought the WRT54GL.

Never got around to that, but I put the router into service anyway, and when I later got more serious about VoIP (which was one of several contributing factors in my switching to Cogeco cable just over a year ago, and later to START's 20/1.5/300 plan last April), the QoS issue raised its ugly head.

Apparently, DD-WRT and Open-WRT also have some sort of QoS too, but I only installed DD-WRT Mini briefly as a way to get Tomato installed, as the factory firmware has its own limit to the .BIN size.

BTW, I was worried that the WRT54GL itself would bottleneck my (then) 30/2 Cogeco feed, but was pleasantly surprised that it did not, EVEN with latest factory firmware at the time, and I tried Tomato anyway sometime afterwards.

I have not needed to buy a newer router so far, and the Shibby build seems 'not too shabby', other than what we just covered here regarding QoS. :)

--

We have only 2 things about which to worry :
(1) That things may never get back to normal
(2) That they already HAVE !
-
START Forum »Start Communications
Or you can still use Canadian Broadband.

Re: Tomato QoS major bug (resolved - normal behavior)

Thu, 03 Jan 2013 13:35:41 EDT

Cloneman posted : Davesnothere,

For cable or VDSL, Toastman will work great (I think). For but ADSL, it requires too much upload to be taken off the table.

I'm looking into adsl specific patches now that can deal with ATM overhead.

»linksysinfo.org/index.php?thread···t-209915

Re: Tomato QoS major bug (resolved - normal behavior)

Thu, 03 Jan 2013 04:00:41 EDT

silvercat posted :

said by Davesnothere:

Which version of Toastman are each of you using, and will it work on Cisco/Linksys WRT54GL router ?

Also it looks like the best firmware (and most updated one) for your WRT54GL router would be from the ND branch (2.4 kernel):
tomato-WRT54G_WRT54GLUSB-1.28.7633.3-Toastman-IPT-ND-VPN

Seems like it has Incoming QOS from "Tiomo", according to the changelog, but i'm not sure the ND branch is being actively developed anymore.

Re: Tomato QoS major bug (resolved - normal behavior)

Thu, 03 Jan 2013 03:48:29 EDT

silvercat posted :

said by Davesnothere:

Which version of Toastman are each of you using, and will it work on Cisco/Linksys WRT54GL router ?

I'm using version 1.28.0500.5 (from the RT-N branch) on an Asus RT-N66U. But there is a newer version that just got released: 1.28.0501

I use the NVRAM64K version, for the N66U.

To enable Incoming QOS, i do nothing special. I'm on the 30/2 package with Start. So i set the upload limit to 1700 KB/sec (maximum - 15%), and the download limit to 30000 (since on a speed test we get around 31000 for the download). It works for me. You could even set the download limit a little less if you wish.

Of course you can get the newest version of Toastman's firmware from here:
»www.4shared.com/dir/v1BuINP3/Toa···79224764

Re: Tomato QoS major bug (resolved - normal behavior)

Thu, 03 Jan 2013 02:07:50 EDT

jibby posted : mine probably wouldn't apply 'cause its on an RT-N16 but i think the QoS stuff is the same in all versions

(but if you're curious im running v1.28.7496 MIPSR2-Toastman-VLAN-RT K26 USB VPN-NOCAT)

i gotta get around to getting my 54GL jtag'd back to life

Re: Tomato QoS major bug (resolved - normal behavior)

Wed, 02 Jan 2013 23:09:18 EDT

Davesnothere posted :

said by jibby:

my router on toastman lists this....

Thanks.

Looks like I should try Toastman's build, if I want to play with QoS again.

Yours & Cloneman's last post are compelling.

Which version of Toastman are each of you using, and will it work on Cisco/Linksys WRT54GL router ?

Re: Tomato QoS major bug (resolved - normal behavior)

Wed, 02 Jan 2013 22:21:27 EDT

Cloneman posted : Davesnothere,

on Shibby's inbound QoS "This is NOT a Global Maximum" is printed. This is where its different than toastman.

Toastman uses a global max for inbound as well. See the screenshot of toastman below, you'll see the inbound QoS looks different than other implementations.

Side Point:
Davesnothere, if you're on Bell or Wholesale (Teksavvy) ADSL, there's yet another issue to deal with.

I've never been able to achieve success without setting my upload max to a rather low value (about 350kbit out of 640kbit). there's some congestion that occurs on mixed up/down traffic stress that I haven't been able to resolved (other than setting my upload max very low). I haven't had the chance to test this with Cable or vdsl

Re: Tomato QoS major bug (resolved - normal behavior)

Wed, 02 Jan 2013 20:46:02 EDT

jibby posted : 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?

Re: Tomato QoS major bug (resolved - normal behavior)

Wed, 02 Jan 2013 18:07:35 EDT

Davesnothere posted :

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.

Re: Tomato QoS major bug (resolved - normal behavior)

Wed, 02 Jan 2013 15:06:30 EDT

silvercat posted :

said by Davesnothere:

Re: Tomato QoS major bug (resolved - normal behavior)

Wed, 02 Jan 2013 11:53:37 EDT

Davesnothere posted :

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

Re: Tomato QoS major bug (resolved - normal behavior)

Tue, 01 Jan 2013 22:14:39 EDT

Cloneman posted :

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.

Re: Tomato QoS major bug (resolved - normal behavior)

Tue, 01 Jan 2013 22:07:13 EDT

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

Re: Tomato QoS major bug (resolved - normal behavior)

Tue, 01 Jan 2013 12:20:18 EDT

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

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

Sun, 30 Dec 2012 21:49:30 EDT

anon posted : 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.

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

Sun, 30 Dec 2012 16:24:59 EDT

Cloneman posted : 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%.

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

Sun, 30 Dec 2012 15:54:02 EDT

graniterock posted : 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.

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

Sun, 30 Dec 2012 14:51:38 EDT

Guspaz posted : 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

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

Sun, 30 Dec 2012 12:49:20 EDT

Cloneman posted : 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.

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

Sun, 30 Dec 2012 12:08:52 EDT

Cloneman posted : 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.

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

Sun, 30 Dec 2012 11:38:32 EDT

anon posted : 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?

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

Sun, 30 Dec 2012 05:14:56 EDT

Cloneman posted : 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

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

Sun, 30 Dec 2012 04:09:54 EDT

Guspaz posted : 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

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

Sun, 30 Dec 2012 00:27:15 EDT

Gone posted : Write your own reference guide. Problem solved.

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

Sun, 30 Dec 2012 00:09:35 EDT

Cloneman posted : 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.

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

Sat, 29 Dec 2012 23:06:34 EDT

Gone posted : 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.

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

Sat, 29 Dec 2012 22:48:48 EDT

Cloneman posted : 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.

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

Sat, 29 Dec 2012 22:44:01 EDT

Gone posted : 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.

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

Sat, 29 Dec 2012 22:37:02 EDT

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

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

Sat, 29 Dec 2012 22:29:27 EDT

Ped_Man posted : 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/

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

Sat, 29 Dec 2012 22:08:45 EDT

Gone posted : 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.

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

Sat, 29 Dec 2012 21:51:04 EDT

Cloneman posted :

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.

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

Sat, 29 Dec 2012 21:43:30 EDT

anon posted : 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.

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

Sat, 29 Dec 2012 21:43:30 EDT

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

Tomato QoS major bug (resolved - normal behavior)

Sat, 29 Dec 2012 20:56:43 EDT

Cloneman posted : 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.