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

[Stonie Cooper]

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.

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.

Giants have fallen off, but are not completely eliminated.  Is this  
something I should be concerned with (having giants)?  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.

Stone

On Aug 1, 2007, at 1:43 PM, Andy Furniss wrote:

> Stonie Cooper wrote:
>> An earlier exchange about someone seeing the rate larger than the  
>> ceiling is posted below.  Andy explained the reason for the "above  
>> ceiling" rate in Daniel's output . . . but I just saw an example  
>> that doesn't fit.
>>  >> tc output >>
>> class htb 1:14 parent 1:1 leaf 14: prio 1 quantum 3072 rate  
>> 256000bit ceil 282000bit burst 1820b/8 mpu 0b overhead 0b cburst  
>> 1851b/8 mpu 0b overhead 0b level 0
>> Sent 2639448 bytes 1128 pkt (dropped 0, overlimits 0 requeues 0)
>> rate 325360bit 17pps backlog 0b 25p requeues 0
>> lended: 981 borrowed: 122 giants: 1155
>
> It's because you have giants - possibly because your nic does tcp  
> segmentation offload so locally generated traffic goes through htb  
> as big chunks before it gets segmented down to the nic's mtu.
>
> You can check/turn that off with ethtool -k or you could use htb's  
> mtu parameter for each rate (I'm not sure if you need to do ceils  
> aswell) which makes the granularity of the rate table bigger so it  
> can handle the larger mtu.
>
> Andy.