[Top][All Lists]
[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