[Top][All Lists]

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

Re: [lwip-users] Issues receiving streaming data

From: address@hidden
Subject: Re: [lwip-users] Issues receiving streaming data
Date: Thu, 30 Jul 2009 17:25:10 +0200
User-agent: Thunderbird (Macintosh/20090605)

Setting PBUF_POOL_SIZE *much* lower than 16 is also not a good idea as this limits the number of RX-packets being processed simultaneously. If you are low on memory, it's a better idea to decrease the size of each pbuf in the pool so that, for a big packet, multiple pbufs are used, while smaller packets (e.g. ACKs) consume less memory.

Also, if you're on a slow system, chances are high the place were a buffer overrun occurs is the ethernet MAC and lwIP won't even notice an overrun (if the MAC driver doesn't record).


JM wrote:
Thank you for the quick reply Kieran. After looking at these settings again, and finding an old post where you give a rough estimate for MEMP_NUM_TCP_SEG, I believe I have this set way too low. I will try your suggestions later and see what happens. Some of the defaults, such as PBUF_POOL_SIZE = 16, is so high it will consume too much RAM. My guess is I can get by with much less. Oops....for the TCP_WND discrepancy, that's easy to explain. I changed it after taking the capture, but it the Wireshark results were basically the same.

I will enable Stats and I can view them with my debugger after it runs for awhile. That is something I haven't thought of before and should give good information. I'll set these numbers high, and try shrinking them until things stop working.

--- On *Thu, 7/30/09, Kieran Mansley /<address@hidden>/* wrote:

    From: Kieran Mansley <address@hidden>
    Subject: Re: [lwip-users] Issues receiving streaming data
    To: "Mailing list for lwIP users" <address@hidden>
    Date: Thursday, July 30, 2009, 10:05 AM

    On Thu, 2009-07-30 at 05:26 -0700, JM wrote:
    > I've included two Wireshark captures in an attached .zip file
    > 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
    > 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
    running out of buffers.  You could confirm this by using the lwIP
    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

    lwip-users mailing list
    address@hidden </mc/address@hidden>


lwip-users mailing list

reply via email to

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