send() blocks when transmitting long buffers on dialup PPP

[hbuciuc at netscape.net]

Hello,

My RTEMS application (server) sends audio buffers to a PC Windows application (client) using TCP/IP.
The client may connect through 100Mbps Ethernet interface or?through?a dialup PPP interface using modems on serial ports.?
For?PPP I have configured the RTEMS "ppp0" interface and the remote PC accepts PPP incoming connections.
After the PPP link is UP and the IP configured with the client may connect over the "ppp0" interface using TCP/IP.
My application is unaware of the interface the client uses to connect, be it "eth0" or "ppp0".
?
When the client connects through the 100Mbps Ethernet "eth0" interface the TCP/IP audio transfer works OK, 
MPC880 instruction cache enabled or not.

When the client connects through the 19200bps (or lower) "ppp0" interface the TCP/IP audio transfer works OK 
only with MPC880 instruction cache disabled.



The problem: the BSD socket send() blocks when transmitting long buffers (8222bytes) 
when the client connects through the "ppp0" interface, with instruction cache enabled.
Short buffers are transmitted OK.



Platform and environment: 
?-Freescale PowerPC MPC880 (=MPC860) at 132MHz + RTEMS 4.6.6
?-RTEMS and my application are compiled -O4
?-MMU, data cache are disabled
?-instruction cache enabled; it?improves processing speed 4-5 times
?-the PPP link is on tty1 (=SMC2) defined as TERMIOS
?-19200 or higher speeds (38400, 57600)
?-modems are 33.6Kbps, XON/XOFF flow control
?-at 19200 the PPP link comes UP all the time, instruction cache enabled or not
?-IP configuration (IPCP): RTEMS defaults (I did not change?the requested parameters)
?-compression (CCP) :no compressions negociated
?-ping works witk 8k+ buffers, instruction cache enabled or not
?-mbuf_bytecount = 256*1024,mbuf_cluster_bytecount?= 512*1024?
?-heap=3MB
?-SO_SNDBUF=8222bytes
?-SO_SNDLOWAT=2048
?-SO_SNDTIMEO=1s + 0us
?-send() is allways called from the same thread

My observations:
?-the few initial short?buffers are?accepted by send() and received correctly?by the PC client
?-the first long 8222bytes buffer passed to send() never makes it completely through the lower layers,?
? parts of the buffer are seen on the serial TX for a while (scope), with long pauses (seconds),
? then after 10-20 seconds nothing is sent 
?-the TCP/IP receive part seems OK (client application?custom KEEPALIVE messages continue to get through)
?-subsequent send() calls for the next buffers return (after 1s normally) errno=EAGAIN=EWOULDBLOCK="No more processes";


-I tried (no improvement):
?-different socket options: 
??-SO_SNDBUF: my buffer to send is max. 8222 bytes so first I tried SO_SNDBUF=n*8222, n = 1,2,8 
?? and then SO_SNDBUF=100,200 etc.
??-SO_SNDTIMEO: tried 0s+0us,1s+0us,20s+0us and 0s+1us (this to make send() behave almost?non-blocking)
??-SO_SNDLOWAT = 1, =1024, =2048
?-to call the second send() only after a delay longer than the time needed to serially xmit the first buffer 
?-to fragment the buffer into 137bytes or less; again only part of or the entire first fragment gets sent on 

? the serial TX (tried it because RTEMS application initial messages-smaller, 30 or 137bytes-are sent OK all the time) 

I stress on this point: if the client connects through the 100Mbps Ethernet the TCP/IP?works OK, instruction cache enabled or not;
TCP/IP?also works on the 19200 dialup PPP with instruction cache disabled.

Can anybody help with a suggestion?

Thanks,
Horia

Check Out the new free AIM(R) Mail -- Unlimited storage and industry-leading spam and email virus protection.




________________________________________________________________________
Check Out the new free AIM(R) Mail -- Unlimited storage and industry-leading spam and email virus protection.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20070716/ec015f49/attachment.html>