lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] TCP performance in receiving


From: Wei Bo-Er \(Jason\)
Subject: Re: [lwip-users] TCP performance in receiving
Date: Mon, 11 Oct 2004 10:49:58 +0800

Hi all,
 
Thanks for your help.
 
I think what Atte said is more close to what I meet. In my case,I saw that TCP
receiving worked well at first. But it got slow down after receivied several
packets. It seems to be that we can't directly send ack via tcp_recved but only
can send it via another packet arrived or tcp_fasttmr. So it gets slow down after
sender has sent TCP_WND size of data.
 
Regards,
 
Bo-Er
 
 
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


_______________________________________________
lwip-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users

reply via email to

[Prev in Thread] Current Thread [Next in Thread]