MBUF Cluster Network freeze problem

Rosimildo da Silva rdasilva at connecttel.com
Wed May 2 12:12:25 UTC 2001


From: "bob" <bobwis at asczone.com>
To: "'Smith, Gene'" <Gene.Smith at sea.siemens.com>
Cc: <rtems-users at oarcorp.com>
Sent: Wednesday, May 02, 2001 2:43 AM
Subject: RE: MBUF Cluster Network freeze problem


> Your hypothesis/description certainly sounds credible to me. After much
> pain, we eventually came to the conclusion that the network stack was
stable
> and the problems were all at the application level. However, pings are
dealt
> with in the network code itself and it is possible that this consumes 100%
> CPU, not giving the App time to empty the other stuff from the MBUF pool.
I
> am not sure, but it could be that the ping handling runs as one of the
> networks tasks and these run at high priority compared with the typical
app
> priority. With RTEMS hard scheduling algorithm the lower priority apps
will
> never get a slice of CPU time.


I have been developing a SOAP server for embedded systems,
and it seems to trigger this problem easily under RTEMS.

When I put the system under heavy load, a SOAP client make exactly 504
requests, and "freezes" for about a minute ( client's timeout ).  This
particular request
times out, and system goes on for aother 504 requests. I see the message
on the RTEMS' console about running low of "MBUFS" before the freeze.

This problems goes away if I do "socket connection pooling" ( resue the
socket )
on the client side ( using Keep-Alive of HTTP 1.1 ).

I would say that for some reason the RTEMS does not "free" right away the
MBUFS on closed sockets, if the system is extremely busy.

Rosimildo.










More information about the users mailing list