On Tue, Jun 28, 2005 at 04:52:17PM +0100, Bob wrote: > I thought the problem was that you needed to limit incoming traffic as > well as outgoing traffic.
i've found that limiting incoming data by queueing on the internal "LAN-facing" interface can be very beneficial if configured correctly. for instance, RTT to my default gateway is normally 12ms. the highest download bandwidth i can realize is roughly 2650 Kb/s. if i am downloading without queueing incoming, pings to the gateway under full-tilt download hover at around 500-700ms. if i set pf to queue incoming at an altq bandwidth of around 2500 Kb/s, i do not find that i lose much in the way of potential download throughput, however under a full-tilt download, the RTT only goes to about 180-300. cutting the altq bandwidth down to about 2400 brings that down further, yielding around a 40-60ms RTT. in a situation where one is trying to use queueing to achieve a high- quality RTT across the circuit to your ISP, queueing on incoming data also could be a very important factor. naturally, a hidden factor would be whether there is a bandwidth shortage leaving the DSLAM/HeadEnd you terminate at, or any other bandwidth shortages further up the food-chain as you traverse your ISPs network. ( eg - if you are provisioned at 3Mb, but there are only a 2 T1s leaving the remote unit, and there are 40 other people on there, it is probably a good idea to be a bit more conservative... in any case, one could run pings to whatever hop on the ISP's network is most applicable, graph them (or whatever) and look. spend a day or two without being involved in large data transfers ) jared - [ openbsd 3.7 GENERIC ( jun 25 ) // i386 ]
