This seems to be correct, my initial calculation didn't take into account the 8 bytes AAL5 tail (which I didn't know about). So, if this reduction effect is due to the AAL5 tail, how come it only shows on tcp acks packets ? The rest of the time, I have an average rate that's around 680kbits/s, which is the expected rate if I only take into account the 5 bytes overhead from ATM without the 8 bytes overhead from the AAL5 packets. Julien On Thu, 25 Mar 2010 22:39:11 +0300, "Nikolay Rybalov" <nowhere@xxxxxxxxxxxxxxxx> wrote: > ATM option accounts for ATM overhead. Single TCP ACK is a 64 byte long, > which is 2 ATM cells (5 byte header each)+ 2 AAL5 tails (8 octets each). > So > single ack is has 16 bytes overhead, or 40%. With 200k ack peaks, HTB > accounts for additional 80k of overhead > > -------------------------------------------------- > From: "Julien Vehent" <julien@xxxxxxxxxxxxxx> > Sent: Thursday, March 25, 2010 9:06 PM > To: "Netdev" <netdev@xxxxxxxxxxxxxxx>; "netfilter" > <netfilter@xxxxxxxxxxxxxxx> > 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 -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
