On 03/25/2010 12:06 PM, Julien Vehent wrote: > 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 Sorry for the late response: could this be an "aliasing" issue caused by sampling intervals (granularity)? -Philip -- 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
