site Search:


 
    All Forums Hot Topics Gallery






how-to block ads


 
Search Topic:
Uniqs:
4704
Share Topic
Posting?
Post a:
Post a:
Links: ·TekSavvy DSL Reviews ·TekSavvy Forum FAQ ·Speedtest results
page: 1 · 2 · 3 · 4
AuthorAll Replies

Cloneman

join:2002-08-29
Montreal
kudos:3
Reviews:
·TekSavvy DSL

2 edits

reply to Cloneman

Re: Cloneman's Tomato QoS Tips for adsl, vdsl2, and cable

for those of you who asked for a starting point, here is mine:

0) Set max upload and download to 85% of Real ISP speed. (you can be more aggressive later - especially on the download side of things w/ ADSL overhead settings)

1) Delete all the default rules, and Rename rubbish class names to something like

1_Highest
2_
3_UDP
4_
5_
6_
7_default
8_
9_Lowest

2) for testing - only 1 rule, priority for UDP traffic (class 3). Everything else default (class 7)



basic settings as follows:



3) 40 bytes overhead for ADSL, 'none' for cable or vdsl

4) try visualware voip testing while hammering your connection. Be sure to click advanced at the end to confirm jitter is less than 8ms and less than 0.5% packet loss, for both upload and download. This is a synthetic test, later you'll use other rules to actually prioritize your real voip connections (although UDP is a catch-all)

Visualware's simulations use UDP so they will have priority.

5) if you want to hammer your connection with torrents, UDP priority will obviously not work because of UTP. In that case, you'll need to prioritize visualware by ports (mine was set to class 2)



This is the starting point from which you work your way up with more complex setups - such as the one I posted on page one of this thread (my current setup). »Re: Cloneman's Tomato QoS Tips for adsl, vdsl2, and cable

neilio

join:2000-08-17
Toronto

Thanks so much for this! I haven't had a chance to test this yet but it's great to have a clear starting point.

I have 25/10 fibre, so I'm not sure if I should implement #3 (40 bytes overhead), and where I'd set that if I should. Otherwise this is a very clear overview.

Edit: Oh, I see, this is the new build with that patch applied. I'm trying to find the latest Toastman build with that added in; may switch to Shibby, though.


Davesnothere
No-BHELL-ity DOES have its Advantages

join:2009-06-15
START&Cogeco
kudos:6

3 edits

said by neilio:

....I have 25/10 fibre, so I'm not sure if I should implement #3 (40 bytes overhead), and where I'd set that if I should.

Otherwise this is a very clear overview.

Edit: Oh, I see, this is the new build with that patch applied.

I'm trying to find the latest Toastman build with that added in.

May switch to Shibby, though.

 
The very recently written DSL patch is in Shibby's latest build #105.

I just installed it over Shibby build #093 from last June and all seems well so far - see posts on previous page of this thread.

Not sure that Toastman has the DSL patch in his yet, even though I do not need it for my Cable service - He did not add it for my older modem's branch (K24 series), last March, but DID include the Tiomo patch (see below) at that time.

Shibby is supporting both older and newer routers and has that patch in all branches, as well as Tiomo's QoS for Inbound mod in all of them - which is part of why I chose his - also that I already had his earlier build and it was stable for me.

Toastman has had the Tiomo patch in all of his builds since early 2012.

Cloneman

join:2002-08-29
Montreal
kudos:3
Reviews:
·TekSavvy DSL

reply to Cloneman
according to my research, the overhead setting is not needed for Bell Fibe 25/10, because this is VDSL. If you router has it, set to to "none". The overhead setting is used to accomodate overhead problems with ADSL because it uses the ATM somewhere down the line, which VDSL does not.

The overhead setting is availble on versions that implement tvlz interface for the tc-atm patch, which has apparently now expanded to shibby.


MaverickHL

join:2006-01-20

reply to Guspaz
With regards to VPN since we are in the topic of QoS. I posted in the generic hardware forums for the router I setup but got no response. Hopefully someone can help explain or give a solution to my situation. So just a bit of context:

- Subscribed to Teksavvy Cable (not that it is too much importance)
- The QoS I had setup only involves outbound related traffic and not inbound
- The router is an Asus RT-N66U which should have plenty of horsepower to run an OpenVPN client.

I subscribed with PIA (privateinternetaccess) and setup the OpenVPN client. After googling around and finding a fancy way to setup certain internal IP ranges to have full VPN access I was pleased with the setup. The issue comes with the Tomato QoS where it can not classify the connections that are using VPN from my assigned range of IP addresses.

I tried setting classification for the IP address range and all the traffic from the VPN IP addresses are not classified and ends up killing those who use it the Internet for local use. So if anyone has any input it would be great.

- MaverickHL


Cloneman

join:2002-08-29
Montreal
kudos:3
Reviews:
·TekSavvy DSL

reply to Cloneman
As your first order of business you'll need a firmware that correctly supports the global maximum for inbound traffic. The latest tomato toastman is what I use (available on his 4shared page), I'm told that shibby has also included this in their (very) recent release)

if something is "unclassified" my assumption is that it falls under "default". Your objective is to classify it somehow, and assign it to a class that is below default (perhaps using the ports that your vpn server privateinterneaccess uses?)

When you click on "connection details" or graphs you should see some information that will help you classify that vpn connection (protocol, port, ip address)

as a bonus You can also prioritize www traffic above default (TCP DEST 80,443 ), in case some unwanted traffic ends up in default

I'm curious to see the results of your findings. If your VPN provider uses UDP, some members here have suggested that you cannot control inbound rates effectively. I would hypothesize that if your router the dropping the hell out of inbound UDP packets, hopefully there's an application level congestion control mechanism (in the absence of a protocol -level one)


MaverickHL

join:2006-01-20

2 edits

Hi Cloneman,

Currently I am using Shibby's firmware at the moment. The last update I did was the December one, I just noticed today that it was updated on the 23rd of January. Not sure if that version will have the support of the global maximum connection for inbound traffic fix.

Just some observations from the "unclassified" side of the VPN. So far what I see is mainly the assigned IP addresses I assigned pointing to the sites it is currently looking at, as well as Google's DNS in UDP (8.8.8.8) and a GRE address. All of these have already been put as a classification of Download in the Tomato USB QoS setup.

What made it difficult for me to actually nail down ports was the fact that after I change settings in the router, the custom WAN IP script I am using that handles the assignment of VPN addresses gets wiped out and I would have to reboot the router (not sure if that is a bug in the firmware).

I can give the latest Shibby a go and see on the weekend as I will have to backup the settings before updating the firmware. With regards to the global maximum connection for inbound traffic, are you referring to the Advanced > Conntrack/Netfilter section of the router?

- MaverickHL


Cloneman

join:2002-08-29
Montreal
kudos:3
Reviews:
·TekSavvy DSL

I'm referring to the max bandwidth limit under inbound, on QoS basic settings page.

Older versions of shibby explicitly say "this is NOT a global maximum!"

As for ports I was hoping you connected VPN provider always connected on the same DESTination port, that would be an easy way to classify.


Davesnothere
No-BHELL-ity DOES have its Advantages

join:2009-06-15
START&Cogeco
kudos:6

3 edits

reply to MaverickHL

said by MaverickHL:

Currently I am using Shibby's firmware at the moment. The last update I did was the December one, I just noticed today that it was updated on the 23rd of January.

Not sure if that version will have the support of the global maximum connection for inbound traffic fix....

....I can give the latest Shibby a go and see on the weekend as I will have to backup the settings before updating the firmware.

With regards to the global maximum connection for inbound traffic, are you referring to the Advanced > Conntrack/Netfilter section of the router?

 
I can confirm that the latest Shibby build #105 DOES have what you are calling the 'global maximum connection for inbound traffic' fix.

That is also known as the Tiomo patch, and was first introduced to us by Toastman, early during 2012.

Shibby did not include it at the time, but now does in all of his #105 builds, including the K24 series for my older WRT54GL router.

Go here »tomato.groov.pl/?page_id=12

Click on 'Changelog', note the build and date (105 and Jan 23, 2013), then click on 'English' for details.

I was successful in my upgrade from an earlier Shibby (#093) without clearing the NVRAM - so far OK, and all of my settings were continued (though some folks say I took a foolish chance on that part, as it sometimes can 'brick' a router).

QoS > Basic Settings > Inbound Rates/Limits > Max Bandwidth Limit is where you set this, and the term 'Global' is not mentioned there, but you will see that the small-print advice on the right of the field looks different at that spot than in your existing build.

I have posted other details earlier in the current thread.

Cheers !

EDIT : OOOOOPS ! - I said Outbound in the bolded path, when I meant to say IN-bound. - I've now changed that.

MaverickHL

join:2006-01-20

reply to Cloneman

said by Cloneman:

I'm referring to the max bandwidth limit under inbound, on QoS basic settings page.

Older versions of shibby explicitly say "this is NOT a global maximum!"

As for ports I was hoping you connected VPN provider always connected on the same DESTination port, that would be an easy way to classify.

The only port provided on the VPN is the one used to connect to the VPN which is just 1194. I could give that a try and map the destination IP address and port which I used in the OpenVPN client and classify that, but I was not sure if that actually would work.

@Davesnothere

I will do an update this weekend then and give it a shot. Would I need to adjust my QoS for inbound? I was under the impression that there is not much control over inbound traffic anyways, so I just let it go as None for everything.

Davesnothere
No-BHELL-ity DOES have its Advantages

join:2009-06-15
START&Cogeco
kudos:6

4 edits

said by Cloneman:

I'm referring to the max bandwidth limit under inbound, on QoS basic settings page.

Older versions of shibby explicitly say "this is NOT a global maximum!" ....

The latest Shibby build (and several of Toastman's) do not make that statement anymore, as the Tiomo patch changed it.

By now not saying anymore that it is NOT, they are in effect saying that it IS - a valid usage of an implied passive-aggressive double-negative in this instance.

said by MaverickHL:

@Davesnothere

I will do an update this weekend then and give it a shot.

Would I need to adjust my QoS for inbound?

I was under the impression that there is not much control over inbound traffic anyways, so I just let it go as None for everything.

Yes, you should, but in that direction, there is only bandwidth management (and not priority of data) classes, and that is why HAVING a Global Max Bandwidth setting there to divvy up will matter so much, and why many of us have been doing/considering this upgrade.

Cloneman

join:2002-08-29
Montreal
kudos:3
Reviews:
·TekSavvy DSL

reply to MaverickHL

said by MaverickHL:

The only port provided on the VPN is the one used to connect to the VPN which is just 1194. I could give that a try and map the destination IP address and port which I used in the OpenVPN client and classify that, but I was not sure if that actually would work.

I would just map the Destination port 1194 in case your VPN provider uses many different ip addresses.

MaverickHL

join:2006-01-20

said by Cloneman:

I would just map the Destination port 1194 in case your VPN provider uses many different ip addresses.

Alright, so after updating to Shibby's last firmware and doing adjustments to the QoS to add destination port 1194 I did a quick test by downloading some files through the VPN.

What I noticed was that my unclassified distribution connection shot through the roof (unchanged from before). The bandwidth distribution however, shows that the VPN is "classified" correctly. Kind of confused as to what that means.

@Davesnothere

I went ahead and adjusted Inbound QoS with default settings from Shibby. I can't tell if it is working though, as the Inbound graphs says it is unused. I am not sure if Shibby actually implemented the inbound graph to pick up incoming bandwidth (bug in firmware?).

Cloneman

join:2002-08-29
Montreal
kudos:3

reply to Cloneman
just set the incoming bandwidth to something ridiculous like 0.5mbps and test...


ema13

join:2009-06-19

3 edits

reply to Cloneman

said by Cloneman:

They are 2 seperate entities. Items that have higher priority on the list will always be prioritized. The bandwith resitricts % is a "bonus" secondary system that should be used mostly to prevent high classes from using _too_much bandwith.

Here's an example setup for upload QoS:

Classifi. type MIN MAX
Priority 1 VoIP 10% 40%

Priority 2 ICMP 2% 10%

Priority 3 HTTP 1% 100%

In this setup, VoiP and ICMP will _ALWAYS_ push http out of the way, even if http is using 100%. For instance when we give ICMP a 10% max, we are saying:

"although we want ICMP to always have priority over http, we don't want the total amount of ICMP traffic to ever exceed 10%"

The purpose of this is that, we assuming that if ever ICMP or VoIP starts using a bunch of bandwith, we're going to assume there's an application misbehaving and we dont want it using up all the bandwith.

If you wanted to, you could set everything to 100% MAX and your QoS would still work, because the most important thing is the order on the list from highest to lowest. My recommendation however is to set some high priorty things to a lower MAX. For example, you could decide that UDP should have a higher priority than http but never use too much bandwith on its own.

I actually made the some of the same assumptions as you which is what inspired making this thread.

Can you explain the purpose of the MIN percentages? If the priority system takes precedence, then it seems that setting a MIN is pointless?

I haven't done any tests nor looked the source code, but by my logic the MIN would need to be set at 100% in order for items higher in the list to always be prioritized. In your example, ICMP would not push http out of the way if http was using 98% of the bandwidth because that leaves the 2% minimum?

EDIT: OK, I've done some tests and it looks like the MIN value determines how much a class can be throttled by classes above it. So it seems that items higher on the list are not always prioritized, they are only prioritized to the extent of the space left by the sum of the MIN values of active classes below them. So let's say a top class wants all the bandwidth, and all 9 classes below have a range of 1%-100% (and are in use), then the top class could only get 91% of the bandwidth. And I guess it is pointless to set a MIN value for the top class? Please correct me if I still misunderstand these QoS settings.

xur17

join:2003-03-26
Cincinnati, OH

I hate to bump up an old thread, but this looks like the most relevant place to post this.

I installed Tomato Shibby with the tc-atm patch. I am confused on what setting to use for "DSL Overhead Value - ATM Encapsulation Type".

I have a Westell 6100 that's configured as a bridge modem for my wrt54gl router. The wrt54gl gets a public wan ip address (non-natted). I know I am supposed to select one of the last four options (RFC2684), and the manual mentions LLC/Snap, so I'm guessing I choose one of those two, but do I choose bridged or routed?


Cloneman

join:2002-08-29
Montreal
kudos:3
Reviews:
·TekSavvy DSL

reply to Cloneman
ema13: you are correct. I didn't know how minimum worked when I made this thread, you summed it up nicely. It's too bad I can't edit the posts now, maybe I'll make an FAQ.

I don't really understand the mechanics behind choosing an overhead value either. I used 32-bytes for PPPoE with an external router and that seemed to work. I guess you can trial and error.

You gotta stress your connection and usual visualware's VoIP tools to see if your settings are working (make sure to prioritize visualware's ports)


Mango
www.toao.net

join:2008-12-25
Alberta
kudos:11
Reviews:
·Anveo
·Shaw
·AcroVoice
·Callcentric
·callwithus
·voip.ms
·FreePhoneLine
·TELUS

2 edits

reply to ema13

said by ema13:

And I guess it is pointless to set a MIN value for the top class?

You can absolutely set a MIN value for the top class. Setting a minimum will "guarantee" that class the minimum amount of bandwidth. (Minimums must add up to 100% or less - you can't guarantee more bandwidth than you have.)

As far as I'm aware, the order of the classes, and their names, is irrelevant. If anyone would like to describe a scenario that I can test to disprove my observations, I will be delighted to do it. [EDIT: See below.]

xur17

join:2003-03-26
Cincinnati, OH

reply to Cloneman

said by Cloneman:

ema13: you are correct. I didn't know how minimum worked when I made this thread, you summed it up nicely. It's too bad I can't edit the posts now, maybe I'll make an FAQ.

I don't really understand the mechanics behind choosing an overhead value either. I used 32-bytes for PPPoE with an external router and that seemed to work. I guess you can trial and error.

You gotta stress your connection and usual visualware's VoIP tools to see if your settings are working (make sure to prioritize visualware's ports)

I tried stressing my system by uploading a file while pinging google.com. ICMP was prioritized (and the upload was lower priority), but there was still a lot of jitter in the connection. I tried a few different Overhead values with the same results. I was getting jumps of ~10ms, and several spikes of 20-30ms. Is that expected?

Cloneman

join:2002-08-29
Montreal
kudos:3
Reviews:
·TekSavvy DSL

1 edit

said by xur17:

I tried stressing my system by uploading a file while pinging google.com. ICMP was prioritized (and the upload was lower priority), but there was still a lot of jitter in the connection. I tried a few different Overhead values with the same results. I was getting jumps of ~10ms, and several spikes of 20-30ms. Is that expected?

Using ping to test QoS doesn't really work for some reason. QoS improves ping, but it's not a good benchmark possibly because it's not a stream of data.

I use the visualware voip website to test my QoS settings. You should get jitter lower than 10ms (upload & download ) and packet loss less than 0.5%. (assuming you have properly priorized Destination port 5060,5061)

Also, I have ICMP prioritized manually on my rules, the checkmark doesn't work for me.

My most recent work in playing with QoS can be found in this thread:

»[Cable] Help Configuring Tomato QoS!

I may decide at some point to make an FAQ because I can't edit old threads :/

I do use use shibby now because it has added the updated QoS rules, like toastman (Tiomo & tc-atm addons)
page: 1 · 2 · 3 · 4

Wednesday, 19-Jun 08:25:59 Terms of Use & Privacy | feedback | contact | Hosting by nac.net - DSL,Hosting & Co-lo
over 13.5 years online © 1999-2013 dslreports.com.
Most commented news this week
Hot Topics