Trevor Blackwell wrote:

>You'll note that the second
>packet sent from port 8002 is not MTU-sized - this causes the receiver
>to not send an ack immediately.

>This has a pretty serious performance impact. It means that a short
>TCP session transferring 2000+ bytes on local network or the loopback
>interface takes a couple hundred milliseconds, rather than a couple
>milliseconds. It means that NetBSD is horrible for webservers.

There are several other problems with the TCP code.
See: ftp.cs.arizona.edu:/xkernel/Papers/tcp_problems.ps

>I figure there are two possible causes:

Nope.  According to the paper it's because the decision to send an ACK
is based on the fact that 2*MSS bytes have been received in sequence.
If the TCP header includes options you won't get full-sized TCP
segments, hence every third segment generates an ACK.  This doesn't
interact too well with the assumption in the congestion avoidence and
fast retransmit algorithms that every other segment is acked.

It is not easy to fix.

I've looked into this last weed to see if it would help with my
problems with the DE-600 pocket adapter but the outcome was
inconclusive.
-- 
Christoph Badura	bad@flatlin.ka.sub.org		+49 721 606137

Es genuegt nicht, keine Gedanken zu haben;
man muss auch unfaehig sein, sie auszudruecken.  - Karl Kraus