Poor network connection causes lockup with V4.6.0pre5

[Joel Sherrill]

Are you possibly in a deadlock waiting for mbufs?  The default
buffer sizes that sockets have is surprisingly high.  I made the
default maximum buffer sizes configurable for 4.9.  I did this
for a user who got into this deadlock situation.  It turned out that it
took 1.5MB of buffers for their few sockets.  I am recalling that
by default a TCP socket can hold 256K of buffers  and a UDP
socket can hold up to 400K buffers.  Combine that with a
few in use by the NIC driver and that is enough to exhaust
most configurations.  You can use SO_SNDBUF/SO_RCVBUF to
tune this down or look at what I did on the head.  The multiplier
of 8 on the single buffer size was horribly excessive in my
experiments and you could save a lot of memory over the
defaults and not impact performance.

Here is the info from the release notes.  I think the network
driver manual online from CVS has a good write up.


> Addition of network stack configuration parameters to control default 
> buffer sizes for sockets. This addresses the issue that was described 
> in http://www.rtems.org/ml/rtems-users/2004/february/msg00200.html in 
> which the default socket buffer tend to be large in comparison to the 
> amount of memory users configure for mbufs. This leads to a starvation 
> and TCP/IP "freeze". This scenario can be created with just a handful 
> of sockets and fairly light traffic and is worsened by use of UDP 
> sockets which default to larger buffering than TCP sockets. See the 
> Network Supplement for more details on each of the following parameters:
>
>     * sb_efficiency - buffering factor or multiplier
>     * udp_tx_buf_size - default size of transmit buffers for UDP sockets
>     * udp_rx_buf_size - default size of receive buffers for UDP sockets
>     * tcp_tx_buf_size - default size of transmit buffers for TCP sockets
>     * tcp_rx_buf_size - default size of receive buffers for TCP sockets
>


Steve Strobel wrote:
> I hate to ask a question about an old version, but it has been
> working well for years and we haven't tried to stay current.  We are
> running RTEMS V4.6.0pre5 on a MCF5272.  The network is used mostly to
> provide telnet connections to a command-line interface.  One of the
> commands causes a relatively large response consisting of about 200KB
> of text.  When that command is executed over a good (LAN or Internet)
> network connection, it works fine.  We recently started testing it
> over a wireless network connection (a D-Link mobile router with a
> Sierra Wireless AirCard 595 over Verizon's EV-DO network) which has
> occasional dropouts, pauses, etc.  A packet sniffer (WireShark) shows
> frequent retries when sending the 200KB chunk.  That wouldn't be a
> problem except that our whole application (running on RTEMS) often
> seems to hang at those times and never recovers.  I am trying to
> track down the cause of the hangups and would welcome any suggestions.
>
> At the risk of narrowing the focus too much...I seem to remember a
> lot of discussion on this mailing list about mbufs:  how many were
> needed, the algorithm used to free them, what should happen when they
> are exhausted, race conditions, etc.  I can't remember if or how
> those issues were resolved nor if they caused symptoms similar to
> what I am seeing.  Does anyone remember the short answer, or should I
> dig through the archives?  My network configuration just uses the defaults:
>
>    0,      /* Default network task priority */
>    0,      /* Default mbuf capacity */
>    0,      /* Default mbuf cluster capacity */
>
> Thanks for any suggestions,
>
> Steve
>
>
>
> ---
> Steve Strobel
> Link Communications, Inc.
> 1035 Cerise Rd
> Billings, MT 59101-7378
> (406) 245-5002 ext 102
> (406) 245-4889 (fax)
> WWW: http://www.link-comm.com
> MailTo:steve.strobel at link-comm.com
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users
>   


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985