Re: TC-HTB issue : low throughput

[Jarek Poplawski <jarkao2@gmail.com>]

Jean Tourrilhes wrote, On 11/07/2009 03:43 AM:

> 	Hi,
> 
> 	I'm playing with a TC-HTB. I'm noticing that the throughput is
> low. As the LARTC mailing list seems to be dead, I would welcome
> suggestions...
> 	The example below may seem contrived, but I reduced it to
> a simple testcase to make it easier to reproduce.
> 
> System :
> ------
> 	Debian Lenny with 2.6.30.9
> 	Quad Core 2.5 GHz Q9300
> 	Intel 1Gb/s NIC, e1000e drive

...

> Topology :
> --------
> Four PCs with Linux :
> 10.10.10.32 on br0
> 10.10.10.33 connected to eth5.33 (sender)
> 10.10.10.38 connected to eth7.38 (sender)
> 10.10.10.34 connected to eth6.34 (receiver)
> 
> Behaviour :
> ---------
> 	If I set only qdisc 1: and class 1:1, but *NOT* 1:2 and 1:3 :
> 	Each host independantly : ~935 Mb/s
> 	Both host together, for 10.10.10.38 : ~527 Mb/s ;
> 	Both host together, for 10.10.10.33 : ~443 Mb/s
> 
> 	If I add classes 1:2 and 1:3 :
> 	Each host independantly : ~170 Mb/s.
> 	Both host together, for 10.10.10.38 : ~106 Mb/s ;
> 	Both host together, for 10.10.10.33 : ~135 Mb/s
> 
> 	So, not only performance did drop significantely, but
> prioritisation did not happen as expected.

If these eths are vlans (or other virtuals) something like this
often happens if you forget to set dev's txqueuelen before
adding classes (or a subqdisc with some 'limit').

> Weird detail :
> ------------
> 	I've noticed that /sbin/tc calculates a very low burst
> value. This is due to the content of /proc/net/psched. I'm wondering
> if the burst calculation is what causes the issue here.
> 	However, I tried with "burst 50kb" and saw no difference...

There is (probably still) unfixed overflow in tc.

BTW, v2.6.31 should be more exact (but so much...) for above 100mbit
scheduling, especially with this patch to iproute2:
http://marc.info/?l=linux-netdev&m=124453482324409&w=2

Jarek P.