On Mon, 05 Nov 2007 22:23:36 -0800 Xamindar <[EMAIL PROTECTED]> wrote:
> I have tried following the howto here: > http://gentoo-wiki.com/HOWTO_Packet_Shaping > But it doesn't work. First of all it ends up limiting both upload AND > download. I have tried a few different ways with all the same result. > Anyone know what is wrong here? === Some "get annoyed and don't read from this point on" stuff :) All that follows represents my personal conclusions based on my personal trial and error experience. These conclusions may be totally wrong. They are not based on any official sources of information. Please, consider seeking answers at the "HTB Home" site: http://luxik.cdi.cz/~devik/qos/htb/ === First. $UPRATE and "$UPCELL" should be equal to each other and *must* be at their maximum equal to your full upload bandwidth as granted by the ISP. Even better if they are a little bit smaller (let's say 5-10%, YMMW). Otherwise the shaper gives unpredictable results such as significant delays followed by uncontrolled bursts. Next. Basically you have 2 choices. (1) To share the unused bandwidth between the classes or (2) to give them strict limits. (1) Shared traffic The sum of the rates should be equal (or less) to the rate of the parent class. In your case: $P2PRATE + $PRIORATE[1-4] = $UPRATE And the individual "cells" should be equal (or less) than $UPRATE (as you have done) This way a given class has "guaranteed" speed = "its rate" and is allowed to take (borrow) the unused traffic from any other siblings (up to the size of its "cell"). In your example 128+65+46+27+8 > 152. Consider changing the values to get equal sign instead of "greater than". (2) Strict limits (I doubt you wont this) Every class has "its rate"="its cell" and the sum of the rates should not be bigger than the traffic allocated for the parent class. This means 1:1 becomes useless in you case. Last. All other cases (like "giving more than one has") seem to me irrational. Please, give some feed back on your results if you decide to follow the above info as advices. -- Best regards, Daniel -- [EMAIL PROTECTED] mailing list
