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