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: Piero 74
Subject: Re: [lwip-devel] application above lwip too low - lwip memp overflow
Date: Thu, 15 Jan 2009 17:11:01 +0100

Hi
just to clarify

1. my application with LWIP works very well... i'm trying to stress the system, and searching some weakness
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....
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)



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... but... i disable nagle alg... is it related to?


Bye
Piero

2009/1/15 Jonathan Larmour <address@hidden>
Piero 74 wrote:
> Hi all
>
> I'm testing performance of my lwip-application. I'm using socket (using
> select in a loop and recv) [lwip release: 1.3.0 stable]
>
> I found a strange problem:
>
> if i will send to my board packets very fast, after sompe packet i will
> have all pbuf of pool in use, and driver will not be able to add new packet.
> But in this situation, i cannot recovery the stack...
> my application after a timeout without packets closes the socket, but
> there is no way to free allcated pbufs
> (see attachment)
>
> there is something in the lwip head that can avoid this problem?

That is strange because lwip_close() calls netconn_delete() which calls
netconn_free() which is in api/api_msg.c, and as you will see there, the
first thing that does is drain the recvmbox - i.e. the mbox containing
queued up pbufs. So it should recover. I don't know why it wouldn't. I
don't see any changes in CVS since 1.3.0 which would have fixed any problem
here.

Is there any chance your driver is not recovering properly from having
pbuf_alloc fail? e.g. no longer generating further interrupts for new packets?

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).

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


_______________________________________________
lwip-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-devel

Attachment: lwip_err_recovery.JPG
Description: JPEG image


reply via email to

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