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. some other bottleneck in the net limiting
one flow to 60Kbit, leaving a full 60k to the other no matter how
weight are assigned).

Note that running this kind of experiments requires a bit of care --
with a 10:1 speed ratio, one of the transfer might complete much faster
than the other leaving full bw to the the other flow for 90%
of the time, which in the end causes both flow to show
approx the same speed.

        cheers
        luigi

> > 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' before the transfer, and provide the output of
> 
> Sure. I've `ipfw zero'ed after both transfers were started.
> 
> >     ipfw show
> 
> 00100   0      0 allow ip from any to any via lo0
> 00100 226 327495 queue 10 tcp from any to any uid dnld1 in
> 00200   0      0 deny ip from any to 127.0.0.0/8
> 00200 677 338406 queue 11 ip from any to any
> 65535   0      0 allow ip from any to any
> 
> >     ipfw queue show
> 
> 00001: 128.000 Kbit/s    0 ms   50 sl. 0 queues (1 buckets) droptail
>     mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000
> q00010: weight 1 pipe 1   50 sl. 1 queues (1 buckets) droptail
>     mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000
> BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
>   0 tcp   AAA.BBB.CCC.DDD/21      XXX.YYY.ZZZ.QQQ/12088  488   693234  0    0   0
> q00011: weight 10 pipe 1   50 sl. 168 queues (64 buckets) droptail
>     mask: 0xff 0xffffffff/0xffff -> 0xffffffff/0xffff
> BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
>   0 tcp   AAA.BBB.CCC.DDD/22      XXX.YYY.ZZZ.QQQ/1022     1       44  0    0   0
>   4 tcp    XXX.YYY.ZZZ.QQQ/12092  AAA.BBB.CCC.DDD/49186  318    12724  0    0   0
>   5 tcp    XXX.YYY.ZZZ.QQQ/12091  AAA.BBB.CCC.DDD/49185  463    18524  0    0   0
>   5 tcp    XXX.YYY.ZZZ.QQQ/12089  AAA.BBB.CCC.DDD/49184    5      204  0    0   0
>  15 tcp   AAA.BBB.CCC.DDD/21      XXX.YYY.ZZZ.QQQ/12088    1       40  0    0   0
>  23 tcp   AAA.BBB.CCC.DDD/21      XXX.YYY.ZZZ.QQQ/12084   30     2153  0    0   0
>  25 tcp   AAA.BBB.CCC.DDD/49183   XXX.YYY.ZZZ.QQQ/12086  207   306124  0    0   0
>  30 tcp   AAA.BBB.CCC.DDD/49182   XXX.YYY.ZZZ.QQQ/12085    4     1455  0    0   0
>  34 tcp    XXX.YYY.ZZZ.QQQ/12084  AAA.BBB.CCC.DDD/21      34     1828  0    0   0
>  46 tcp    XXX.YYY.ZZZ.QQQ/12088  AAA.BBB.CCC.DDD/21      24     1220  0    0   0
>  46 tcp    XXX.YYY.ZZZ.QQQ/1022   AAA.BBB.CCC.DDD/22       2       84  0    0   0
>  48 tcp   AAA.BBB.CCC.DDD/49186   XXX.YYY.ZZZ.QQQ/12092  317   469668  0    0   0
>  52 tcp    XXX.YYY.ZZZ.QQQ/12086  AAA.BBB.CCC.DDD/49183  207     8284  0    0   0
>  53 tcp    XXX.YYY.ZZZ.QQQ/12085  AAA.BBB.CCC.DDD/49182    5      204  0    0   0
> 
> >     ipfw pipe show
> 
> 00001: 128.000 Kbit/s    0 ms   50 sl. 0 queues (1 buckets) droptail
>     mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000
> q00010: weight 1 pipe 1   50 sl. 1 queues (1 buckets) droptail
>     mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000
> BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
>   0 tcp   AAA.BBB.CCC.DDD/21      XXX.YYY.ZZZ.QQQ/12088  488   693234  0    0   0
> q00011: weight 10 pipe 1   50 sl. 168 queues (64 buckets) droptail
>     mask: 0xff 0xffffffff/0xffff -> 0xffffffff/0xffff
> BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
>   0 tcp   AAA.BBB.CCC.DDD/22      XXX.YYY.ZZZ.QQQ/1022     1       44  0    0   0
>   4 tcp    XXX.YYY.ZZZ.QQQ/12092  AAA.BBB.CCC.DDD/49186  318    12724  0    0   0
>   5 tcp    XXX.YYY.ZZZ.QQQ/12091  AAA.BBB.CCC.DDD/49185  463    18524  0    0   0
>   5 tcp    XXX.YYY.ZZZ.QQQ/12089  AAA.BBB.CCC.DDD/49184    5      204  0    0   0
>  15 tcp   AAA.BBB.CCC.DDD/21      XXX.YYY.ZZZ.QQQ/12088    1       40  0    0   0
>  23 tcp   AAA.BBB.CCC.DDD/21      XXX.YYY.ZZZ.QQQ/12084   30     2153  0    0   0
>  25 tcp   AAA.BBB.CCC.DDD/49183   XXX.YYY.ZZZ.QQQ/12086  207   306124  0    0   0
>  30 tcp   AAA.BBB.CCC.DDD/49182   XXX.YYY.ZZZ.QQQ/12085    4     1455  0    0   0
>  34 tcp    XXX.YYY.ZZZ.QQQ/12084  AAA.BBB.CCC.DDD/21      34     1828  0    0   0
>  46 tcp    XXX.YYY.ZZZ.QQQ/12088  AAA.BBB.CCC.DDD/21      24     1220  0    0   0
>  46 tcp    XXX.YYY.ZZZ.QQQ/1022   AAA.BBB.CCC.DDD/22       2       84  0    0   0
>  48 tcp   AAA.BBB.CCC.DDD/49186   XXX.YYY.ZZZ.QQQ/12092  317   469668  0    0   0
>  52 tcp    XXX.YYY.ZZZ.QQQ/12086  AAA.BBB.CCC.DDD/49183  207     8284  0    0   0
>  53 tcp    XXX.YYY.ZZZ.QQQ/12085  AAA.BBB.CCC.DDD/49182    5      204  0    0   0
> 
> Irrelevant udp/icmp traffic was snipped, IP's were masked to protect the
> innocent ;) `ipfw pipe show' and `ipfw queue show' look both very similar - hmm.
> 
> Best regards, /S
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-net" in the body of the message
> 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message

Reply via email to