der Mouse,
Is it possible that the 'maxburst' restriction of 4 segments
(max. back to back segments that tcp_output can send)
is causing this ?
Why are the acks so delayed ?

Venkat

der Mouse wrote:

> I'm seeing poor TCP throughput.  It looks to me as though the window is
> 32K but there's never more than about 9K of data in transit.
>
> 23:58:06.258331 A.1657 > B.25: . 1898546:1899046(500) ack 433 win 16384 <nop,nop,timestamp 2042828 1736756472>
> 23:58:06.973542 B.25 > A.1657: . ack 1896046 win 32500 <nop,nop,timestamp 1736933640 2042821> (DF)
> 23:58:06.976479 A.1657 > B.25: . 1899046:1899546(500) ack 433 win 16384 <nop,nop,timestamp 2042829 1736756472>
> 23:58:06.979960 A.1657 > B.25: . 1899546:1900046(500) ack 433 win 16384 <nop,nop,timestamp 2042829 1736756472>
> 23:58:06.983378 A.1657 > B.25: . 1900046:1900546(500) ack 433 win 16384 <nop,nop,timestamp 2042829 1736756472>
> 23:58:07.697526 B.25 > A.1657: . ack 1896546 win 32500 <nop,nop,timestamp 1736933712 2042822> (DF)
>
> Is this a known problem?  Anyone have any idea what's up?  A is a
> machine on my house LAN, NetBSD/sun3 1.2 (soon to be replaced with
> something a little more recent); B is probably a penguin machine of
> some stripe, though I can't see that the peer OS matters when the
> problem is that my end is using only some 8K or 9K of an offered 32K
> window.
>
> I've also seen bad performance between a 1.4T machine at home and
> another 1.4T machine elsewhere, sometimes bad enough that the
> connection eventually breaks.  (I mention this only by way of
> comparison; I don't have a tcpdump of such a connection, so it's hard
> to say anything definite about it.)
>
>                                         der Mouse
>
>                                mouse@rodents.montreal.qc.ca
>                      7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B