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
> and the problems were all at the application level. However, pings are
> 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.
> 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
> priority. With RTEMS hard scheduling algorithm the lower priority apps
> 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
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
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.
More information about the users