On Tue, 15 Oct 2002, Lars Eggert wrote:
> Paul Herman wrote:
> >
> > Not true. Although some bugs have been fixed in 4.3, FreeBSD's
> > delayed ACKs will still degrade your performance dramatically in
> > some cases.
>
> I'm sorry, but such statements without a packet trace that exhibits the
> problem are just not useful.
</me reels line back in>
Aha! Another victim who is willing to take a look at this! :-)
It's an issue that was left unresolved in kern/24645. Bruce Evans
brought this to my attention back during the unrelated "I have
delayed ACK problems" thread on -net in January of 2001 and I then
passed it on to jlemon. If you need a packet trace, let me know,
but you should be able to reproduce it yourself. Even today on my
4.7-PRERELEASE I still get:
mammoth# sysctl net.inet.tcp.delayed_ack=0
net.inet.tcp.delayed_ack: 1 -> 0
mammoth# time tar cf 127.0.0.1:/tmp/foo /kernel
0.000u 0.041s 0:00.33 12.1% 350+300k 0+0io 0pf+0w
mammoth# sysctl net.inet.tcp.delayed_ack=1
net.inet.tcp.delayed_ack: 0 -> 1
mammoth# time tar cf 127.0.0.1:/tmp/foo /kernel
0.014u 0.033s 0:45.90 0.0% 700+600k 0+0io 0pf+0w
^^^^^^^
It seems that lowering lo0 mtu to 1500 makes this particular
problem go away. The magic mtu size is 2100. This makes me think
that this is a big problem across GigE using 8K jumbo frames, not
sure. Also, taring over the IPv6 lo0 interface seems to work OK.
No idea what causes this.
-Paul.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
