netdev - QoS weirdness : HTB accuracy

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 for Android: free password hash cracker in your pocket

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

Date:	Thu, 25 Mar 2010 19:06:34 +0100
From:	Julien Vehent <julien@...uxwall.info>
To:	Netdev <netdev@...r.kernel.org>,
	netfilter <netfilter@...r.kernel.org>
Subject: QoS weirdness : HTB accuracy

Hello folks,

I observe unused bandwidth on my QoS policy that I cannot explain.
Conditions are: I have a HTB tree with 8 classes and a total rate of
768kbits. I use the ATM option so I assume the real rate to be something
close to 675kbits (about 88% of the ethernet rate).

The sum of my 8 rates is exactly 768kbits. Some have ceil values up to
768kbits.

When class 20 "tcp_acks" starts borrowing, TC reduces the total bandwidth
down to 595kbits/S (minus 79kbits/s). And I can't explain why....

The attached graph "tc_htb_weirdness.png" shows the result: there are
'holes' in the sending rate. 

I tried to play with burst sizes, r2q value and hysteresis mode, but the
results are the same.

System is debian squeeze, kernel version is 2.6.26, iproute2 version is
2.6.26 - 07/25/2008.

I have attached two files:
- "tcrules.txt" : the traffic control rules
- "tc_htb_weirdness.png" : the rrdtool graph, resolution is 1 second.

And here: http://jve.linuxwall.info/ressources/code/tc_hole_analysis.html
a sheet with some of the measures values. I used it to calculate the size
of one of the hole. The last table (with green and red cells) shows that,
when class 20 "tcp_acks" starts sending at unixtime 1265496813, there is a
lot of bandwidth left over (last column is all green). During the 95
seconds while class 20 is sending, 3880776 bits could be sent but are not.
That's about 40kbits/s on average. 

Does anybody observess the same behavior? Any logical explanation to this
or is it a bug ?

Julien
View attachment "tcrules.txt" of type "text/plain" (2619 bytes)

Download attachment "tc_htb_weirdness.png" of type "image/png" (29681 bytes)