Reviews:
 ·TekSavvy DSL
3 edits | Cloneman's Tomato QoS Tips for adsl, vdsl2, and cableThis is not a guide! These are tidbits of information anyone embarking on a QoS journey will find useful. I have spent many hours in a laymen's journey discovering what QoS is and isn't, sometimes at my expense on this and other boards :P
TL;DR at bottom
This is just some good reading material if you've followed big guide before and failed.
(1) These tips are for Tomato Toastman edition.
(2) Download / Inbound QoS works very well on Toastman - I think the only thing that can slip through the cracks it is a Denial of service attack or a seriously misbehaving UDP application (utorrent behaves very well).
(3) Is is my suspicion that inbound QoS doesn't work correctly on any other firmware (unless of course, they implement Toastman's QoS :P). Other firmwares, like shibby, and possibly regular tomato, do not have a "global maximum" for inbound QoS, which makes them highly impractical for most setups.
(4) Even tomato toastman, in all it's glory, does not work properly for ADSL! You need a special build for all ADSL connections, which need to compensate for overhead on an ATM network. I've set mine to 40 bytes. See this thread:
»linksysinfo.org/index.php?thread···l.31541/
tvlz is currently compiling Toastman builds with this patch.
If you don't use a build like this, you have to take 50% of the upload traffic off the table, or your QoS won't work. Technical details:
»ace-host.stuart.id.au/russell/fi···/tc-atm/
You do not need this special build for Cable or VDSL2 (Bell Fibe), Tomato Toastman should be fine (though I don't have a connection to test with at the moment).
If you're currently on ADSL and you think your tomato QoS works, well, you just haven't stressed upload and download at the same time to try and break it :^)
(5) Some users with very high speed connections (50mbps) have reported that even a powerful router (480Mhz) , is cpu underpowered with QoS on. I can't help you guys :P
(6) My method of testing if my QoS works, is applying various mixed stress to the line (torrents, FTP uploads, http) and using the VoIP tester @ Visualware at the same time. Of course, you need to add visualware to your high priority class (DEST port 5060, 20000, and 20001)
(7) The Class is rank (highest to lowest) is more important than the maximums you set. You can give VOIP 20% maximum and it will have priority over your HTTP traffic that you've assigned as 100%, for example)
(8) You should rename The class names (1-10, keep it simple) and delete all the predefined rules before starting your journey.
(9) Uncheck prioritize small packets, (all 4 of them), and be sure to check off "Reset class when changing settings"
(i'll update this thread as neccessary to clarify)
TL:DR;
Inbound QoS works, but ONLY on Toastman Tomato.
QoS on Regular adsl is probably defective on 99% of implementations, needs a special build of Toastman Tomato with TC-ATM patch. Not needed for Cable or VDSL2.
|
|
Reviews:
·TekSavvy DSL
1 edit | using the TC-ATM patch (for ADSL connections) observations:
Downstream bandwidth seems to be lower than expected, but for some odd reason, setting a proper max value doesn't seem to impact performance.
I set my downstream way above my line rate and I couldn't get my VoIP packets to drop or jitter... lol |
|
DavesnothereNo-BHELL-ity DOES have its Advantages
join:2009-06-15
START&Cogeco
kudos:6 | said by Cloneman:reserved for future use....
The FUTURE, Conan ?
I have done this in other threads which I have started.
Bear in mind that after 5 days, each post gets locked by the system anyway.
However, within that constraint, if you are after post position, you've got it. 
= = = = = =
BTW, this post gives me position #3 in your thread for the next 5 days, if I have something to say which I figger to be important enough to put here, instead of my current jibber-jabber.  |
|
brad
join:2007-09-06
Etobicoke, ON | reply to Cloneman
You cannot enforce QoS inbound on a connection after the traffic has gone across the link. It HAS to be done at the other end, as in the ISP side. |
|
Reviews:
·TekSavvy DSL
| said by brad:You cannot enforce QoS inbound on a connection after the traffic has gone across the link. It HAS to be done at the other end, as in the ISP side.
Yeah, so this probably relies on cooperation from the other end, Dropping ACKs and what not. The question is, when would the other side not cooperate?
It seems to work well enough. I've tried stopping and starting multiple downloads during a VoIP test, and I wasn't able to cause increases in jitter. If you've got some type of traffic I can generate to break my setup, I'll be glad to try it |
|
Mangowww.toao.net
join:2008-12-25
Alberta
kudos:11 Reviews:
 ·Anveo
 ·Shaw
·AcroVoice
·Callcentric
·callwithus
·voip.ms
·FreePhoneLine
·TELUS
| said by brad:You cannot enforce QoS inbound on a connection after the traffic has gone across the link. That's true, but that's not how QoS (at this level) works. Most people don't realize you can reduce the requests you send to effectively throttle inbound traffic. Regardless of whether or not you use bold text,  Tomato's QoS works, in both directions, and it works well.
said by Cloneman:The question is, when would the other side not cooperate? So far I've never encountered such a situation. In the past ~2 years I've been using it, it's always performed exactly as configured. |
|
brad
join:2007-09-06
Etobicoke, ON | said by Mango:That's true, but that's not how QoS (at this level) works. Most people don't realize you can reduce the requests you send to effectively throttle inbound traffic. Regardless of whether or not you use bold text, Tomato's QoS works, in both directions, and it works well.
Not all IP traffic is TCP. This cannot work properly.
said by Mango:So far I've never encountered such a situation. In the past ~2 years I've been using it, it's always performed exactly as configured.
That doesn't prove anything. |
|
Mangowww.toao.net
join:2008-12-25
Alberta
kudos:11 | What are some examples of traffic you suspect would not work as expected? |
|
Reviews:
·TekSavvy Cable
| reply to Cloneman
QoS provides a better quality experience by doing two main things: prioritization and traffic shaping.
Prioritization : instead of the default of passing traffic on in the same order it is received higher priority packets are sent before lower priority.
Traffic shaping : limiting the transmission of some traffic types or even all outbound traffic.
-------------------------
Short scenario:
- VOIP set to higher priority - the VOIP packets jump ahead of other packets
- All outbound traffic shaped to 95% of capacity - buffers in other network gear like the Cable or DSL Modem are kept mostly empty so they don't introduce a buffering delay to all outbound traffic when utilization is high |
|
DavesnothereNo-BHELL-ity DOES have its Advantages
join:2009-06-15
START&Cogeco
kudos:6 | said by BrianON:QoS provides a better quality experience by doing two main things: prioritization and traffic shaping....
Yes, and between those two factors and managing the bandwidth of your other apps (such as p2p) individually/internally, things can work VERY well. |
|
 GuspazGuspazPremium,MVM
join:2001-11-05
Montreal, QC
kudos:20 | reply to Cloneman
For outbound, your router can prioritize VoIP packets even if the connection is saturated. For inbound, all you can do is rate limit, so the only way to pretend to be a slower link than you actually are, and hope enough of your traffic is TCP that slowing that down frees up enough space for the VoIP packets.
--
Developer: Tomato/MLPPP, Linux/MLPPP, etc »fixppp.org |
|
Reviews:
 ·WIND Mobile
·TekSavvy Cable
·TekSavvy DSL
| reply to Cloneman
said by Cloneman:(5) Some users with very high speed connections (50mbps) have reported that even a powerful router (480Mhz) , is cpu underpowered with QoS on. I can't help you guys :P
When I went from DSL 6 to Cable 28/1 I had to say goodbye to my Asus WL-520gU if I wanted QOS at speeds higher than 20 Mb/s down. The router seemed to struggle even with it off. I splurged and got the RT-N66U which has worked great since then. I am very thankful for Tomato because I know I wouldn't have been able to ditch my landline for VOIP without it. |
|
| reply to Guspaz
Guspaz,
can you give an example for some type of UDP application that would persist to push more downstream than you can take? |
|
zincPremium
join:2004-02-17
Kitchener, ON | Many non-TCP based VPNs. |
|
GuspazGuspazPremium,MVM
join:2001-11-05
Montreal, QC
kudos:20 | reply to Cloneman
It doesn't have to send you more than you can take, only as much as you can take. The VPN example is a good one; most VPNs use UDP (or occasionally GRE, which would have the same issue). There would typically be TCP inside of the UDP tunnel, and that would be doing congestion control, but all that means is that it'll max out the link, and you can't prioritize inbound packets. You're left with the same solution; rate limit your inbound to well below the actual limit except for high priority packets... And since you can't control the queuing on the remote end, that's still going to leave you with a sub optimal situation in terms of latency and jitter.
The two factors of QoS are rate limiting and prioritization. On inbound, it's impossible to do BOTH of those, you can only rate limit.
In a well-configured and well-designed outbound QoS system, you don't need to rate limit yourself below your maximum speed, because prioritization can simply ensure that any high-priority packets get sent out immediately, jumping the queue. On inbound, you have no control over the prioritization on the remote end, so you have to make sacrifices that limit your potential performance.
--
Developer: Tomato/MLPPP, Linux/MLPPP, etc »fixppp.org |
|
Reviews:
·TekSavvy DSL
| reply to Cloneman
I'll have to try UDP VPN stress then.
The only real UDP traffic I've tried is uTorrent, which probably implements it's own congestion control at the application level.
I should note that for some reason, with the TC-ATM patch for ADSL, I'm getting good performance no matter how high I set my downstream max (even 4-5 times greater than my line capacity). |
|
|
|
Reviews:
·TekSavvy Cable
| reply to Guspaz
said by Guspaz:In a well-configured and well-designed outbound QoS system, you don't need to rate limit yourself below your maximum speed, because prioritization can simply ensure that any high-priority packets get sent out immediately, jumping the queue. There are buffers even on the upstream side that you don't have control over to prioritize packets. On cable with a slow 256kbps upstream even a small 32kb buffer in the cable modem is a full second of traffic which if your VOIP packet gets stuck behind can cause problems. |
|
mikefxu
join:2004-10-05
Titusville, FL | reply to Cloneman
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. |
|
Reviews:
·TekSavvy DSL
4 edits | this is largely a draft, work in progress. I've given UDP more than it needs, ideally I'd set the UDP downstream max to maybe 50% for most people
My actual "real speed" is 16.5 Mbits download and 0.68 mbits upload.
I'm using the 40byte TC-ATM patch because it's adsl2+. I've been very aggressive on the downstream max, because in my particular case, it doesn't seem to matter.
(No limit) Classes are not used.
For torrents, you can specify an incoming range in utorrent for easy classification. (not sure if I did this right) |
|
mikefxu
join:2004-10-05
Titusville, FL | Can you also screenshot the QoS Basic Settings, just above the DSL Overhead Value? |
|
