[Top][All Lists]

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

Re: [lwip-users] Issues receiving streaming data

From: Kieran Mansley
Subject: Re: [lwip-users] Issues receiving streaming data
Date: Thu, 30 Jul 2009 15:05:19 +0100

On Thu, 2009-07-30 at 05:26 -0700, JM wrote:
> I've included two Wireshark captures in an attached .zip file (please
> add .zip to filename).  The one labeled "lan" is when the server was
> my computer on my LAN, and the one labeled "wan" is a streaming audio
> server on the Internet.  I've verified these both work fine when a
> computer is is playing the stream.  On the "lan" trace, there is a
> perfectly repeated Dup ACK and retransmission that should not be
> happening.  On the "wan" trace, the connection just seems to break
> down before I close it.  This is similar behavior to all other
> Internet streaming audio servers, so it's not just this one.  

The retransmissions are happening because there are packets being
dropped.  They are repetitive because after packet loss the sender is
very cautious about the sending rate.  As soon as the sending rate
increases, you see packet loss.  This suggests strongly that your lwIP
device can't handle > 1 packet arriving at a time, and so you're likely
running out of buffers.  You could confirm this by using the lwIP stats,
and seeing which of the buffer types are reporting errors (if you can
get a print out of these somehow).

Looking at your settings, I think it would be good to change:

MEMP_NUM_PBUF: you'll need more than one of these, I'm pretty sure.
PBUF_POOL_SIZE: 3 seems rather small.  What's the default here - see
MEMP_NUM_TCP_SEG: only having 2 TCP segments is going to cause you
LWIP_UDPLITE: you can probably set this to zero
TCP_SNDBUF: you could set this larger (smallest sane size is two MSS)
without using any extra memory, but probably not the source of your
problems as you're not sending much.

Something that looks odd to me is that you're setting TCP_WND to 2920,
but in the packet captures lwIP is giving out a larger receive window of


reply via email to

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