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.htmlBasically, 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