lwip-users
[Top][All Lists]
Advanced

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

Re: [lwip-users] Duplicate ACK problem with LWIP 1.3.2


From: Kieran Mansley
Subject: Re: [lwip-users] Duplicate ACK problem with LWIP 1.3.2
Date: Wed, 6 Jan 2010 19:47:29 +0000

On 6 Jan 2010, at 16:20, Hafiz Bashir wrote:

> Hi,
> 
> We seem to have a problem when using LWIP 1.3.2 to request a large file from 
> a remote server. Our target is an ST7101 running OS21.
> 
> Our application uses the netconn API to request a large file from a remote 
> server using HTTP GET
> 
> From what I can see from Wireshark, the transfer begins OK with correct ACK's 
> being sent.
> 
> However at what appear to be random points during the transfer, I start to 
> see duplicate ACK's. It seems LWIP is sending the same ACK for the next few 
> segmemts it receives.
> 
> I have experimented with adjusting the TCP_WND size in lwipopts.h with mixed 
> results. It would appear that if TCP_WND > 8*TCP_MSS, then we start seeing 
> the duplicate ACK problem. TCP_MSS is set to 1460. However having a lower 
> TCP_WND size results in a lower transfer performance.

I've had a quick look at your log (as Simon says, a wireshark pcap file is much 
more useful) and it looks fine to me.  The duplicate ACKs indicate that there 
has been some lost packets.  The sender spots the duplicate ACKs and 
retransmits the missing frames using the fast retransmit algorithm, and then 
everything carries on as it should.  This is TCP working properly to recover 
from loss.

The reason for the loss is perhaps another question.  If you see it when you 
increase the window size (which as you point out increases performance) then I 
would guess that it's due to running out of some resource at the receiver, 
which seems in this case to be lwIP.  With a small window size the window will 
limit the performance so that the receiver can keep up and doesn't drop 
packets.  With a larger window size the network will be able to deliver packets 
fast enough to overwhelm the receiver.  You might be able to solve this by 
adding more of whatever the resource (e.g. packet buffers) is that is running 
dry.  The LWIP_STATS stuff might help you identify what it is.

Hope that helps.

Kieran



reply via email to

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