Re: NetBSD 5.1 TCP performance issue (lots of ACK)

[Havard Eidnes <he%NetBSD.org@localhost>]

> To diagnose this, I recommend making a tcpdump of the traffic with
>
> tcpdump -w TRACE tcp
>
> and then using  tcpdump2plot in graphics/xplot-devel.
>
> I am not clear if graphics/xplot-devel (or /xplot) has caught up to
> minor changes in NetBSD tcp

I'm more familiar with the graphs which tcptrace can produce.  It can
make time/sequence plots (ref. the -S option) which are well
understood by graphics/xplot, at least last I looked.

> From the stats, it looks like there is loss in the data stream causing
> SACK.  But I don't see how there would be 237850 pure acks for ~98K data
> packets; there should be more like 49K.

I agree, the traditional behaviour is that NetBSD TCP acks every
second TCP segment.

There doesn't appear to be all that much retransmission, though; only
54 data packets have been retransmitted in the "connection 5" example,
although the retransmission rate *is* non-zero, so some packets may
indeed go missing in the network somewhere, which is never a good
recipe for high TCP performance.

Generally, the congestion control algorithm used by default by Linux
these days is a bit more agressive when ramping up the congestion
window ("how much data can we send before having to wait for an ack")
after an idle period or after a packet loss event, it *may* be that
the effect of this is what you're seeing.

When you say that "NetBSD with Linux performs well", which end in this
setup is the sender of the majority of data?  If it's the Linux end,
that could be a further hint that it's the TCP congestion control
algorithm variants which plays a role.

Regards,

- Håvard