Hi Daniel,

I'm not 100% sure I've gotten the traffic shaper nailed down, but as 
far as I've been able to learn, the way to make a "dynamic bandwidth 
limiting" is something along these lines (I hope people will correct 
me if I'm wrong?):

(For simplicity this is for one direction only, simply duplicate for 
other dir.)

- Make a pipe with a limitation somewhat smaller than your actual 
bandwidth (ie. just a tad below your measured bandwidth, as best you 
can test it with a nearby speedtest). Don't put anything in the "Mask".

- Make two (or more) queues, bound to the above pipe, each with 
different weights (this is the "ratio" of the bandwidth each queue 
will get, although I can't find the exact formula used, it certainly 
doesn't seem to be a normally calculated "ratio"?) I find that you 
need rather "steep" ratios for this to give any significant share (I 
use 2, 32 and 96 for my low, medium and high priority queues, and 
still don't get quite what I want on medium, when low is using the 
full bandwidth.)

- Make some rules using the above queues for different kinds of 
traffic. Typically you want to have these work on the WAN interface 
(in both directions, filtering on source for outbound traffic and 
destination for inbound).

That should be it (but as mentioned you need to repeat the entire 
process for traffic in the opposite direction).

= = =

Some notes (remember that this is also purely based on my guesses and 
observations of the shaper at work):

- The "Mask" should cause a seperate pipe or queue to be created for 
each source or destination host. This is typically used to get a 
static sharing of bandwidth (ie. you make a pipe/queue with some 
percentage of the total bandwidth, and set the mask to source for 
outbound and destination for inbound, causing one pipe/queue in each 
direction to be created per local host. Swapping source and 
destination will cause one pipe/queue to be created for each remote 
host.) I'm not entirely sure in which cases you should do this for the 
pipe, for the queue or for both? (Personally I use masking only for my 
DHCP'ed local wireless hosts, as these are for "guests" which should 
have only a quarter of the total bandwidth each, since I rarely have 
more than four guest hosts at once. I've choosen to mask the pipes, 
while keeping the queues unmasked, but I'm far from sure this is the 
way to go?)

- You can make rules that bypass the queues and go straight to a pipe. 
My guess is that this works something like an extra high priority 
(ratio), as the packets should be inserted ahead of anything in the 
queue(s). I use this for things such as ACK's and DNS, as these are 
small packets, which greatly improves performance if they are 
transfered as quickly as possible (I've made sure to limit the packet 
sizes in the rules, to prevent larger packets being handled this way).

- Remember that (as far as I know?) the shaper rules are applied after 
NAT (like firewall rules), thus you will need to use the local IPs in 
any rules where NAT is involved.

- For the shaper to work, the total traffic (ie. through all pipes, 
including the "virtual" ones created by masking) must never exceed 
your actual (real-world, after overhead has been subtracted) 
bandwidth, especially not in the outbound direction. If it does, it 
will be your ISP or modem (or whatever) that limits/queues the 
packets, effectivly disabling the shaper (or at least limiting its 
effectivity). Thus, when limiting dynamically (ie. without masks and 
typically through a single pipe in each direction) the pipes should 
have a limit a bit below the fastest speed you can measure through 
your internet connection. When doing static, per host limiting (ie. 
with masks, typically masking on the local hosts), the limit of the 
(masked) pipes should be such that number of hosts times the pipe 
limit never exceedes the maximum bandwidth of the connection.

- All rules should typically work on the WAN interface, unless you 
specifically want to limit the bandwith of inter-LAN traffic (or 
perhaps traffic between LAN and any OPTx interfaces). The only reason 
I can see for limiting the LAN traffic, would be to reserve some 
bandwidth for high priority LAN traffic, or to ensure that there is 
always bandwidth available for internet traffic or some such.

I hope this helps (and that it is all correct?)


Regards,

Adam.