Re: [lwip-users] TCP performance in receiving

[K.J. Mansley]

On Fri, 2004-10-08 at 10:05, Wei Bo-Er (Jason) wrote:
> Hi All,
>  
> I am using lwip 1.0.0 and meet a problem in TCP performance. I found
> that TCP performance much dependents on usage of connection.
> A  connection which sends & receives packets alternately will get
> much higher perfoemance than the one which only receives packets.
> This seems due to that tcp_ack will always set pcb->flag to
> TF_ACK_DELAY in tcp_receive. I guess doing so is for waiting to see if
> there is any packet to be sent later and ack can also be sent in that
> packet. But as a connectionis is always in recving packets, each ack
> will 
> always delay about 250ms and then it can be sent. This will much
> reduce TCP performance.

I thought that the stack should, if asked to send an ACK when one has
already been delayed, send a dedicated packet out at that point.  i.e.
There should only be one outstanding delayed acknowledgement at once. 
This would mean that if as in your case the stack is only receiving
data, it would send ACKs for every other packet, rather than wait 250ms
as you report.

The implementation of tcp_ack() backs this up:

#define tcp_ack(pcb)     if((pcb)->flags & TF_ACK_DELAY) { \
                            (pcb)->flags &= ~TF_ACK_DELAY; \
                            (pcb)->flags |= TF_ACK_NOW; \
                            tcp_output(pcb); \
                         } else { \
                            (pcb)->flags |= TF_ACK_DELAY; \
                         }

If the TF_ACK_DELAY flag is already set, it is cleared, and TF_ACK_NOW
set instead.  The call to tcp_output() should then dispatch the
acknowledgement straight away.

However, as this doesn't match what you are seeing, there might be
something wrong.  I'm not sure what though.

Kieran