netdemo: TCP locks up after echoing 11K

[Joel Sherrill]

Arnout Vandecappelle wrote:
>  Hoi,
>
>  I'm developing an Ethernet driver and testing it with the netdemo.  It
> seems to work OK, except that the echo servers hang when data is sent
> too fast.
>
>  I use netcat to send a large file to the echo server.  I use tcpdump to
> watch the actual data sent.
>
>  The client (a PC) dumps the first 57344 bytes of data very quickly on
> the network.  Of these, 36376 are actually sent out by TCP and
> acknowledged by the RTEMS board.  The echo server sends back 18488 bytes
> of data.  Of these, only 1536 bytes are actually sent on the network
> (and acknowledged): the echo server blocks when trying to send the next
> 512 bytes.  At this point, the two TCP end point continue exchanging ACK
> packets indefinitely.  The client doesn't send anything more since the
> receive window is full.  Why the server doesn't continue sending, I
> don't know...
>
>  Note that the communication between the ethernet chip and the CPU is
> very slow, which leads to some packets being dropped.  However, I don't
> think that should be an issue: the missing data is retransmitted.
>
>  My guess is that the RTEMS TCP stack has consumed all its transmission
> buffer space, but still needs to allocate an extra mbuf to start the
> next transmission.  Can anyone confirm this theory?  Can anyone think of
> a fix?
>
>  By the way, I'm using 4.6.99.2, but I've looked at the CVS version and
> don't see any major differences with this respect.
>
>   
A few thoughts

+ you should be getting a message if you are out of mbufs.

+ Print the TCP/IP statistics when the failure occurs.

+ driver could be losing packets and the stack is out.  But no
message being printed makes this unlikely.

+ sockets can consume a LOT of memory if you get behind.  The
CVS trunk has some new tuning parameters for socket default
buffering.  There are also standard BSD ioctl's to control this
on per socket.  But this all just would run you out of mbufs.

+ You could be missing an interrupt.

-joel
>  Regards, and thanks,
>  Arnout
>
> --
> Arnout Vandecappelle                     <arnout at mind.be>
> Senior Embedded Software Architect       +32-16-286540
> Mind Embedded Development (an Essensium division)
>
> _______________________________________________
> 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