> Well. It is not the case I think. Both transfers were for big files (~200MB
> each). I've zeroed the counters after start. Measurments are acuurate according
> to both rules as well as lftp status messages.
actually the counters you sent me only showed some 300Kbytes per transfer
(which amount
On Wed, 3 Jan 2001, Luigi Rizzo spake thusly:
> So i believe you have done some mistake in your config or your
> measurement (e.g. some other bottleneck in the net limiting
> one flow to 60Kbit, leaving a full 60k to the other no matter how
> weight are assigned).
I really don't think so. Only th
Hi,
i have just run a test locally (on a 4.2R system, queues with weight
1 and 10, transfers on different tcp port) and the results
are exactly what one would expect -- one flow gets 10 times the bw of the
other one.
So i believe you have done some mistake in your config or your
measurement (e.g
On Mon, 1 Jan 2001, Luigi Rizzo uttered the following:
> it should not be equal provided the 'high weight' flow has sufficient
> traffic going.
Both FTP transfers I've used for testing were around 60Kbps each. One done by
user dnld1, the other one by other user.
> Can you do an 'ipfw zero' befor
> I tried to configure dummynet to allow for normal work when downloading files
> using queue mechanism (4.2-STABLE).
>
> IPFW rules are:
>
> add 100 queue 10 tcp from any to any uid dnld1 in
> add 200 queue 11 ip from any to any
>
> queue 10 config weight 1 pipe 1
> queue 11 confi
I tried to configure dummynet to allow for normal work when downloading files
using queue mechanism (4.2-STABLE).
IPFW rules are:
add 100 queue 10 tcp from any to any uid dnld1 in
add 200 queue 11 ip from any to any
queue 10 config weight 1 pipe 1
queue 11 config weight 10 pipe 1 m