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).
Simon
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
> (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
> src/include/lwip/opt.h
> MEMP_NUM_TCP_SEG: only having 2 TCP segments is going to cause you
> problems
> 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
> 4380.
> Kieran
>
>
>
> _______________________________________________
> lwip-users mailing list
>
address@hidden </mc/compose?to=
address@hidden>
>
http://lists.nongnu.org/mailman/listinfo/lwip-users>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> lwip-users mailing list
>
address@hidden>
http://lists.nongnu.org/mailman/listinfo/lwip-users_______________________________________________
lwip-users mailing list
address@hiddenhttp://lists.nongnu.org/mailman/listinfo/lwip-users