Re: [lwip-users] TCP performance in receiving

[Atte Kojo]

K.J. Mansley wrote:
> 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.

This is because tcp_recved() only does an ack if there are no acks 
pending (delayed or otherwise):

if (!(pcb->flags & TF_ACK_DELAY) &&
    !(pcb->flags & TF_ACK_NOW)) {
    /* ... comment deleted ... */
    tcp_ack(pcb);
}

This effectively nullifies the tests in tcp_ack() in this case. I 
resolved this problem (probably not very cleanly) by adding an extra 
else to above test that sends out an ack if there is already a 
TF_ACK_DELAY pending on the pcb and the receive window is big enough.

I had the same problem when doing an application that only receives a 
huge amount of data without sending out anything.

        - Atte

--
GARLIC GUM IS NOT FUNNY
GARLIC GUM IS NOT FUNNY
GARLIC GUM IS NOT FUNNY
GARLIC GUM IS NOT FUNNY

        Bart Simpson on chalkboard in episode 7G13