dslreports logo
 
    All Forums Hot Topics Gallery
spc
Search similar:


uniqs
6671
graniterock
Premium Member
join:2003-03-14
London, ON

graniterock to Cloneman

Premium Member

to Cloneman

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

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

Cloneman

Member

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

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

1 edit

Cloneman

Member

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

silvercat

Member

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

Cloneman

Member

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
Change is NOT Necessarily Progress
Premium Member
join:2009-06-15
Canada

2 edits

Davesnothere to Cloneman

Premium Member

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

silvercat

Member

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
Change is NOT Necessarily Progress
Premium Member
join:2009-06-15
Canada

Davesnothere

Premium Member

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

jibby

Member

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?
Cloneman
join:2002-08-29
Montreal

Cloneman

Member

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

Davesnothere
Change is NOT Necessarily Progress
Premium Member
join:2009-06-15
Canada

Davesnothere to jibby

Premium Member

to jibby
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 ?
jibby
join:2008-03-31

jibby

Member

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

silvercat
join:2007-11-07

silvercat to Davesnothere

Member

to Davesnothere
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/v1Bu ··· 79224764
silvercat

silvercat to Davesnothere

Member

to Davesnothere
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.
Cloneman
join:2002-08-29
Montreal

1 edit

Cloneman

Member

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.ph ··· t-209915

Davesnothere
Change is NOT Necessarily Progress
Premium Member
join:2009-06-15
Canada

4 edits

Davesnothere to silvercat

Premium Member

to silvercat
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/inde ··· 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.
Cloneman
join:2002-08-29
Montreal

Cloneman

Member

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/45a8764123 ··· 57490213

If you're using Cable or VDSL, regular toastman builds are fine.
mikefxu
join:2004-10-05
Titusville, FL

mikefxu

Member

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/45a8764123 ··· 57490213

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
Cloneman
join:2002-08-29
Montreal

Cloneman

Member

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.
mikefxu
join:2004-10-05
Titusville, FL

1 edit

mikefxu

Member

said by Cloneman:

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