Re: eth_recv out of MBUFs

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




Hi Stano,

I've had a similar problem and found some help in this message:

http://ecos.sourceware.org/ml/ecos-discuss/2003-10/msg00350.html

and the followup:

http://ecos.sourceware.org/ml/ecos-discuss/2003-10/msg00380.html

Basically, I've used the suggested hack to reduce the time required for TCP connections to timeout. Fiddling around with the number of permissible open connections did not end well...

--
Wayne Visser
LSZ PaperTech Inc.



On 11-08-09 02:36 AM, Stanislav Meduna wrote:
On 05.08.2011 09:51, Lambrecht Jürgen wrote:

Be carefull: the eCos freeBSD stack has no timeouts on TCP connections I
believe, but often the PC stack has!
Well the TCP timeouts that are in place when the connection
is not sending any data are basically unusable on any
standard-conforming TCP/IP stack. Whoever designed
SO_KEEPALIVE the way it is specified was smoking something
quite strong...

So the eCos TCP session stays alive, but the PC (used to test) stack
shuts down the TCP connection when the cable breaks (after a timeout, or
it can also detect the cable fault). And the TCPs are out of sync
(something like that), and then it uses a lot of sockets, and indeed (as
in your next mail) the timeouts are very big to free sockets.
If that is your problem, I can ask my college: he recompiled ecos to
change the minute timeout to seconds.
This is most probably not the source of the problem I am seeing
in this test setup. Thanks for the hint anyway.

With a slow device and big burst of data, I had to increase the space
for mbufs.
Well, but to what size? I'd like to know the formula to calculate
the worst-case mbufs needs based on the number of active TCP
and UDP sockets... I am probably asking for too much :(

My gut feeling is that the TCP windows of all open connections
do not fit into the allocated mbufs. I'll try to tune this
stuff - unfortunately the FreeBSD stack is not really
friendly here.

Better use lwIP on memory-constrained devices. And lwIP is more actively
maintained..
This is on my todo list for quite a long time - unfortunately
there are issues that have to be solved first. AFAIK lwIP
is not thread-safe on a single socket level and our present
framework does read from and write to a single socket from
different threads :/

I have also no idea whether everything from eCos we are
using/planning to use is able to work with lwIP (e.g. SNMP).


Regards

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss



[Linux Embedded]     [U-Boot V2]     [Linux Kernel]     [Linux MIPS]     [Linux ARM]     [Linux for the Blind]     [Linux Resources]     [Photo]     [Yosemite]     [ISDN Cause Codes]     [ECOS Home]

Add to Google Powered by Linux