Doug,
On AIX the ACKs are triggered by application's
reading of the data. An NFS client sets MSG_WAITALL
recv() flag. Which means the data is not delivered to the
apps till the full 32K arrives.  Without the application's
read delayed ACK kicks in which is upto 200 millisecs.
And the sender is waiting for the ACK for the cwnd to
increase to send more.
We have done changes to this MSG_WAITALL behavior
and if you use one of the recent releases (AIX 5.1 for example)
you will not see this problem.
Venkat

Doug Donsbach wrote:

> I'm seeing something that seems strange to me regarding
> AIX as an NFS v3 TCP client to our NetBSD server. Both
> are on 100Mbit Ethernet. The server is using tcp_output.c
> v 1.74 from a 1.5Y-ish code base.
>
> The client does a 32K read. The server responds to the
> 32K read withing a few tens of microseconds with 4 packets.
>
> After a very long delay, 200-300 milliseconds, the client
> acks. Within a few tens of microseconds, the server responds
> with 3 packets.
>
> This process repeats until the read is satisfied. There are
> no retransmitted packets and the client is always offering
> a window much larger than the server is filling.
>
> Needless to say, this results in read transfer rates in the
> tens of kilobytes.
>
> A Solaris client on the same network behaves in a similar
> fashion, except delays only 200-300 microseconds before
> acking.
>
> If I defeat "Congestion Window Monitoring" by setting tcp_cwm
> to zero, each client seems happy and read performance is as
> expected.
>
> My question is, doesn't it seem like the cwm logic is a little
> broken?
>
> Doug
> --
> Doug Donsbach - dldonsbach@tds.net