hi again "Basic": does anyone care to explain What "No Limit" does for a class? "Classification" What does setting a traffic type to "Disabled" (instead of 1 of the 10 classes) do? Porter: I'm leafing through this thread, of course a lot of the information is out of date. A lot has changed, with the advent of faster connections, the new/improved (and router CPU heavy) incoming QoS, and ADSL2+ TC-ATM patches. Anyplace I should be looking as I dig deeper? (to be honest, I haven't gone past page 1 of this thread, the rest is all from personal testing)
No Limit basically breaks QoS because that class has no limitations on bandwidth, while all the other classes do. The only classes I set to No Limit are classes I don't use. Disabled class disables the rule, it doesn't disable QoS for that rule.
Cool, that's what I thought, that's what I do as well. I was thinking of setting a "No Limit" for connects to my ftp server's IP address, as an alternative to disabling QoS when I want the fastest possible speed and don't care about breaking QoS (as an alternative to temporarily turning off QoS). I'm guessing "No Limit" for a minimum value would mean 0% reserved bandwidth? (just asking for curiosity, don't think I would find a us for this)
No Limit for a minimum value would mean, effectively, 100% for reserved bandwidth. But it's outside the scope of QoS, so it doesn't even count as 100%. The rest of the classes will try to guarantee bandwidth that, basically, isn't there. You can set all classes to No Limit/No Limit for Incoming, or Outgoing, to disable QoS for that direction. That's the safest way I know of to use No Limit.
I removed "no limit" purposely some time ago because there were some strange reports by people who had used it. Somehow it crept back in after a merge by someone else. Recently, I removed it again. Porter, do you see any advantage in keeping it?
I can't really investigate this matter since my version (Toastman-IPT-ND-7634) doesn't have the "no limit" value any more. If somebody wants me to investigate it, I would appreciate some small excerpt of /etc/qos with and without the "no limit" setting. This setting could be useful for people who have a large downstream which can't be handled by the router with QoS enabled. But whether this setting actually uses less CPU power... that I don't know. I noticed people using "no limit" because they thought it would make there traffic even faster. In this scenario I think it's destroying QoS, because you should just put your important traffic in a high enough class and give it a maximum of 100%. Sure, the guaranteed bandwidth rates might be deducted but most of the time this traffic probably doesn't use much bandwidth. Keep in mind that the safety margin that needs to be applied to upstream and downstream on ADSL has decreased since the overhead patches. Even less reason to use "no limit". It's a difficult decision to make because I have seen too many people using "no limit" in the wrong way, at least from my standpoint. On the other hand I think there should be an option to disable downstream QoS. Maybe this could be done with some java script. I imagine a box, that when ticked, just sets all classes in downstream direction to no limit. That way we don't need yet another variable...
An option to disable downstream QoS to save CPU cycles is a cool idea. Anecdotal evidence from a few people would suggest that connections between 40-50+mbit have problems with the new QoS framework (the one where incoming QoS actually works, i think you guys call it Tiomo or IMQ based, but some people say it uses more CPU%). I don't think these people had success using "No Limit" to alleviate CPU usage %. I would imagine the QoS engine classifies all incoming traffic even if you have "No Limit" set. The only way to alleviate CPU would be for engine to not classify/process incoming traffic, if that's even possible. As for using No Limit for 1 class, I don't think it's working right now. (full disclosure, I'm playing with shibby at the moment). Using No Limit does not seem to bypass the global maximum on the downstream, for me. EDIT: If I could make a quick suggestion, "DSL overhead value" perhaps there should be a notice that says "not needed for VDSL". or something like "helps adsl, adsl2+, not needed for VDSL, cable, and fiber"
I tend to agree, I don't see much benefit from "no limit" any more, but I do see many people destroying their QOS with it. Any running code will consume CPU time, and the incoming QOS will have an overhead, of course. My own personal belief is that the QOS is better now than it was, and I'm not sure about setting only "outgoing". The forums have been full for years with comments like "incoming QOS doesn't work" and so on, and doing that will only reinforce their erroneous beliefs. The real answer is, we need faster routers. I can't do it myself, but I'd love to see Tomato running on i386 ...
Sure, incoming QoS is better now (it was broken before in my opinion). I'm not one of the people who has problems, (my connection is 30mbit maximum). As long as it's clear in the UI that incoming QoS is turned off, I don't see why it would add to the confusion. Heck, it's still confusing now because only a few tomato versions have the "new" downstream QoS and it's not obvious which releases those are to most people. (latest shibby and Toastman are the ones I know have it). I would like to see experimentation options with incoming QoS totally disabled for users who have very fast downstream connections. EDIT: e4200v1 Shibby, downloading @ 30Mbit w/ QoS on does not produce more than 0.15 load for me, however, so those with slower routers and faster connections should be the ones advocating for experimentation on this.
Toastman: Actually I can't remember anyone saying that incoming QoS doesn't work. I Haven't seen this in any thread lately. Maybe people finally got the idea... cloneman: Agreed to change it to ADSL. Thinking about it, "no limit" almost certainly doesn't use less CPU power. Unless proven otherwise I vote for removing it. A simple workaround to deactivate downstream QoS might be this: Code: iptables -t mangle -D PREROUTING -i ppp0 -j IMQ --todev 0 tc qdisc del dev ppp0 root 2>/dev/null Depending on when the WAN UP script gets executed the above could be placed there. While we are at it: could someone please put a hint on the QoS and B/W Limiter pages telling people not to use them both at the same time? This has been one of the most common errors around here in recent times.
