Re: [ECOS] eth_recv out of MBUFs

[Wayne Visser <wvisser@lszpaper.com>]

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