lwip-devel
[Top][All Lists]
Advanced

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

Re: [lwip-devel] application above lwip too low - lwip memp overflow


From: Jonathan Larmour
Subject: Re: [lwip-devel] application above lwip too low - lwip memp overflow
Date: Fri, 16 Jan 2009 17:19:23 +0000
User-agent: Thunderbird 1.5.0.12 (X11/20070530)

Piero 74 wrote:
> 2. i found this strange problem on lwip yesterday, bombing an open
> socket with a lot of packet... but now i'm not be able to reproduce the
> problem... but i'm sure i will not have problem on the field, during
> normal work.
> 3. Stressing my application, i found another situation, but this is a
> behaviour i want:
> seeing attachment, you can see that i have some mem err in my driver
> (application too slow), the driver discards packet and memp memory was
> freed....

Yes that sounds like what's meant to happen.

> i really don't know what was happened yesterday... but i wanted to
> report here, 'cause it could be a deep problem (as kieran said)
> Obviously, i will check my code again and again and again.... :O)

It could be some very obscure bug certainly, but we'd need more information
to be able to find out what's wrong. For all we know, it could be your own
hardware going wrong, your own application that is scribbling over memory
it doesn't own, or your own driver which isn't handling some situation
correctly. As Kieran said, from past experience, these sorts of things
often turn out to be driver problems.

>     As for the general problem of running out of pbufs in the first
>     place, you
>     may wish to reduce your TCP receive window (TCP_WND in lwipopts.h).
> 
> 
> i didn't understand this... sorry... :O( i didn't use this option...

The receive window is the starting point for what you tell the remote peer
how much data it can send. It's per-connection, so it's a bit of a
balancing act - ask yourself how many connections you want to support, and
how much received data should be able to be buffered, given your available
pbuf pool memory. But typically if you have less memory it's best to reduce
the window, to avoid running out of pbufs which reduces efficiency
(although that is meant to be something which can be recovered from). If
you have lots of pbuf pool memory, you can increase the default receive
window to improve efficiency.

> but... i disable nagle alg... is it related to?

No that's different, Nagle is to do with when you really send enqueued TCP
data.

Jifl
-- 
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["Si fractum non sit, noli id reficere"]------       Opinions==mine




reply via email to

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