netdev - Re: TC-HTB issue : low throughput

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4AF60349.8000502@gmail.com>
Date:	Sun, 08 Nov 2009 00:31:21 +0100
From:	Jarek Poplawski <jarkao2@...il.com>
To:	jt@....hp.com
CC:	netdev@...r.kernel.org
Subject: Re: TC-HTB issue : low throughput

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.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html