Re: QoS weirdness : HTB accuracy

[Julien Vehent <julien@linuxwall.info>]

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@hakkenden.ath.cx> 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@linuxwall.info>
> Sent: Thursday, March 25, 2010 9:06 PM
> To: "Netdev" <netdev@vger.kernel.org>; "netfilter" 
> <netfilter@vger.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