[Top][All Lists]

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

[lwip-users] out of pbuf's

From: Mark Six
Subject: [lwip-users] out of pbuf's
Date: Thu, 3 Jul 2008 14:22:56 +0200 (CEST)
User-agent: SquirrelMail/1.4.11

Hello all,

I'm experiencing some problems with lwip-1.3.0. I hope the list can
provide me some guidance.

I have lwip running on a LPC2468, this processor has about 64 KB of
memory. The goal is to serve at least 4 tcp/ip connections.

On those 4 connections data is transmitted randomly (packets from appr. 20
bytes every 10 milliseconds). Data that is received is echo'd back.

If I make 2 connection from the PC with for example telnet I see the data
is received. If I enter something in the telnet session, I get an echo.
Indeed all is well.

However if I send more data (I just copy and paste a text file into
telnet)from the PC to the LPC-board, lwip sometimes runs out of PBUF's and
all incoming data is dropped. The connections are dropped/dead and it
takes a few minutes for lwip to accept incoming packets again.

What I think has happened is the following:

For each incoming ethernet packet, one or more pbuf's are allocated. The
number of pbuf's available is defined by the PBUF_POOL_SIZE.
If there are no more pbuf's available (e.g. all pbuf's are allocated) the
incoming ethernet packet is dropped. The TCP/IP stack handles the incoming
packets and will free them. If the packet is a data-packet, the
application layer is responsible for freeing the packet.
However if the packets come out of sequence, the pbuf is *NOT* free'd, but
placed on the oos queue. If the out-of-sequence packets are equal to the
PBUF_POOL_SIZE the lwip-stack is in a deadlock for some time (until some
timer times out and frees the oos queue).
To limit the number of out-of-sequence packets one could adjust the
receive window size (TCP_WND), however it is possible that one packet can
have only 1 byte of data, so the value for the receive window can be no
more than the available pbuf's divided by the maximum number of TCP

This is a problem, because we need a lot of memory or a very small receive

Any comments on the above are welcome..


Mark Six

reply via email to

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