lwip-users
[Top][All Lists]
Advanced

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

Re: [lwip-users] Query amount of free buffers


From: Marco Jakobs
Subject: Re: [lwip-users] Query amount of free buffers
Date: Thu, 25 Mar 2010 17:08:50 +0100
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3

Am 21.03.2010 13:27, schrieb address@hidden:
The netconn API is no more thread-safe than the netconn API: The lack of thread-safety (which is really only a lack of full-duplex thread-safety) in the socket API comes from the fact that it uses the netconn API. As long as you are only using one socket from one thread at a time, there is not problem.

OK ... good to know. :-) But i see no advantage to rewrite it from the netconn API to the socket API, as everything works fine (and i have no knowledge to the socket API yet).

However, with nonblocking-write, the problem should be solved with the netconn API as well.
But in this case we *have* still all buffers full.
Not really: these are only the per-connection limits that are reached. That doesn't mean all buffers are used. Other connections (or UDP) may still use more buffers. lwIP TCP has 2 limits per connection: the number of pbufs enqueued (TCP_SND_QUEUELEN) and the number of bytes enqueued (TCP_SND_BUF). Both may be configured much smaller than the actual available buffers!

This is a valueable information, Simon. And it works! :-)

I have put my critical UDP connection to an extra task, that one has now the higher priority. Also i have reviewed the priorities of the tasks ... as the "old" IP server task had a higher priority than the main task, the main was not interrupting the IP server task, which was waiting for new free IP buffers in that case. So my watchdog saw a task failure and resetted the system.

Now no TCP connections are handeled with a higher priority than the rest of the system, so it never get stuck when there are no free TCP buffers. And indeed, in the stuck situation my UDP communication continues working pretty well ;-)

So no need to go to a CSV branch ... i'll remain with the stable 1.3.2.

But still i have to deal with some buffer configuration ... my settings, which worked out good for my limited memory resources are:

#define MEMP_NUM_PBUF                   16
#define PBUF_POOL_SIZE                  64
#define PBUF_POOL_BUFSIZE               128

#define TCP_WND 2500 // Muss mindestens 2xTCP_MSS sein!
#define TCP_MAXRTX                      3
#define TCP_SYNMAXRTX                   3
#define TCP_MSS                         512
#define TCP_SND_BUF                     1024


The TCP_SND_QUEUELEN is still at the default setting of opt.h:
#ifndef TCP_SND_QUEUELEN
#define TCP_SND_QUEUELEN                (4 * (TCP_SND_BUF)/(TCP_MSS))
#endif

So the calculation of TCP_SND_QUEULEN will result in 8. Does this mean that TCP may use 8 out of 16 (MEMP_NUM_PBUF) buffers?

Marco






reply via email to

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