[LARTC] tc shown rate larger than ceil (was "Weird rate in HTB")

[Stonie Cooper]

Andy - I spoke too soon; there were evidently just a few giants left  
in the queue when I did the change.  After an hour, all giants  
ceased.  Thanks again - it works much better now.

Stone

On Aug 1, 2007, at 4:26 PM, Andy Furniss wrote:

> Stonie Cooper wrote:
>> Andy - Thanks!
>> I took the ethtool path, and turned off tcp segmentation on that  
>> nic; I was unsure how to set the HTB MTU - I use shorewall on a  
>> Gentoo system.
>
> I think you would need to find each line with a rate in the script  
> and add mtu X - I don't know what X would be, though.
>
>> It has definitely made a difference.  The highest rate I see is  
>> 282312bits on a line with a ceil of 282000bits - and that is with  
>> 24pps, which, according to your previous email . . . would be  
>> right in line with what it should be.
>
> If you are shaping for a wan then I would turn off tso rather than  
> use mtu. It should be better for latency as a big chunk of data is  
> going to take more time to be transmitted and hurt interactive  
> traffic. I can't imagine it being very good to effectively drop  
> multiple segments at once either - but then shorewall may not setup  
> with queues short enough to get drops.
>
>> Giants have fallen off, but are not completely eliminated.  Is  
>> this something I should be concerned with (having giants)?
>
> As long as there aren't many I wouldn't care - I don't know why you  
> still see them, though. I haven't got any nics that do tso so can't  
> test.
>
>   Would setting the
>> HTB MTU be more elegant?  I have avoided creating my own tc  
>> script, and have been using shorewall's internals . . . but if  
>> utilizing the HTB MTU setting is "better", I will dive in and try  
>> to write a script that does the same thing as shorewall.
>
> You would also loose some accuracy in the rate lookup tables if you  
> used mtu 16,32,64 etc. bytes depending on how big an mtu you needed  
> to use.
>
> If you have a slow dsl link and really care about latency or not  
> having to back off from it's rate, then there are other ways to  
> tweak things. They involve patching and recompiling kernel/tc.
>
> Andy.