We noted this problem that the first subclass got all the extra bandwidth when the subclasses should be sharing the extra bandwidth equally. We were able to get it working better by lowering the quantum to 1600.
I think what is happening with a larger quantum is that the first subclass is getting all the extra bandwidth in one quantum.
Orlie
On Monday 2003.06.16 10:07 Albert Martorell wrote:
Hi everybody!
I've been trying with htb and tc filter. It seemed to work fine, but after testing with ethloop I've realized that traffic is not being distributed through the leaves as I thought. When sending packets to 1:10 and 1:11 at the same time, there's no bandwidth sharing. There's no traffic through 1:11 until traffic through 1:10 has finished. Though I've tried assigning different prio's, 1:10 always gets more bandwidth...
Here's the script that reproduces this behaviour:
tc qdisc add dev eth0 root handle 1: htb default 12 r2q 10 tc class add dev eth0 parent 1: classid 1:1 htb rate 600kbit ceil 600kbit tc class add dev eth0 parent 1:1 classid 1:10 htb rate 200kbit ceil 600kbit tc class add dev eth0 parent 1:1 classid 1:11 htb rate 200kbit ceil 600kbit tc class add dev eth0 parent 1:1 classid 1:12 htb rate 200kbit ceil 600kbit tc qdisc add dev eth0 parent 1:10 handle 20: sfq perturb 10 tc qdisc add dev eth0 parent 1:11 handle 21: sfq perturb 10 tc qdisc add dev eth0 parent 1:12 handle 22: sfq perturb 10
tc filter add dev eth0 protocol ip parent 1: u32 match ip sport 53 0xffff flowid 1:10 tc filter add dev eth0 protocol ip parent 1: u32 match ip src 1.2.3.4 match ip sport 80 0xffff flowid 1:11
Thanks in advance!
Albert
_______________________________________________ LARTC mailing list / LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
