Re: [ECOS] Odd TCP behavior

[Andrew Lunn <andrew dot lunn at ascom dot ch>]

On Tue, Oct 02, 2001 at 10:14:48AM -0500, Grant Edwards wrote:
> I've notice an odd behavior of the eCos TCP stack.  I've got an
> application that does this:
> 
> Host    ----> Command        eCos
>                Resp1 <----   
>                Resp2 <----
> 
> All messages are 5-6 bytes long, and the Host is advertising a
> window size of at least 8K.  It takes 5-10ms to generate Resp1
> and another 5-10ms to generate Resp2.

> The eCos TCP stack apparently waits to send Resp2 until it
> receives an ACK for Resp1.

If the Nagel algorithm has not been disabled, this delay is
normal. The nagel algorithm says that TCP should not send a TCP
segment which is not full when there is an outstanding ACK. The Nagel
algorithm can be disabled with the TCP_NODELAY socket option. Maybe
you linux host software has this option set and the NT not. Really,
your eCos application should also set this socket option.

> When the Host is Linux, Resp1 is ACKed immediately, and
> everything works fine.
> 
> When the Host is NT4, the ACK for Resp1 is delayed for about
> 100ms, and eCos won't send Resp2 until it sees the ACK for Resp1.

Delayed Acks is also normal. The hope is that the Host will send
something back to the target and TCP can piggyback the ACK onto the
data. So the host waits a while and then gives up and sends the ack. 

Now, Linux seems to be a bit cleverer than NT (no comment) and does
not use delayed acks when the connection is new. This helps TCP slow
start phase finish as soon as possible so that the full bandwidth of
the link is used. After a while Linux will also start using Delayed
ACKs.
 
> This delays Resp2 for 100ms, which results in really bad
> latency problems.  (It takes 170ms to complete the transaction
> instead of the expected 10-20ms.)
> 
> Shouldn't eCos keeps sending packets until the window has been
> filled?

Depends on the socket options. Try setting TCP_NODELAY and see if its
any better.

    Andrew