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.
_______________________________________________
LARTC mailing list
LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
