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

[Stonie Cooper]

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
tokens: -48548 ctokens: -56127
<< tc outpu <<

I see a 43360 difference, where the rate is more than the  
ceiling . . . of which only 952bits are accounted for in the  
following exchange.  I have actually seen the rate be as much as  
80408bits off . . . at only 19pps.

Is there something else I am missing?

Stone


Daniel Harold L. wrote On Tuesday 03 July 2007 22:50:
 >> Dear all,
 >>
 >> First, sorry for my bad English ..
 >>
 >> To night one of my client is the victim of UDP attack from  
internet. It's tons
 >> of UDP packets from internet with destination to port 80. But  
when I look at
 >> class of that victim client, the actual class rate is over than  
configured
 >> rate class.
 >>
 >> Below is my screen capture. You can see at class 1:913 which have  
actual rate
 >> 105136bit while configured with ceil at 96000bit. Also it's  
parent class
 >> (1:91) which have actual rate 107680bit while configured with  
ceil at
 >> 96000bit.
 >>
 >> Is this normal? Or I have miss something in my script. Sometimes  
ago I found
 >> this situation but I forgot to capture the screen and the traffic  
is UDP too
 >> (maybe from torrent-like client)
 >
 >Yes it is normal!
 >
 >The rate tables that tc use normally have an 8 byte steps, so it is
 >possible for up to a 56bit/s error per packet and you have 300 pps.
 >
 >There was a small patch submitted for tc to make the error fall on the
 >underrate rather than overrate side, but I think it got lost in the
 >middle of the long ATM overhead patch thread on netdev.
 >
 >Andy.