<br>


<div id=AOLMsgPart_2_d5ead4b6-d847-4ae4-be7f-44089ad47e29>

<div id=AOLMsgPart_2_77ee22d0-0813-434c-8328-5510862ac387>

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


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


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


<div>Platform and environment: <br>
 -Freescale PowerPC MPC880 (=MPC860) at 132MHz + RTEMS 4.6.6<br>
 -RTEMS and my application are compiled -O4<br>
 -MMU, data cache are disabled<br>
 -instruction cache enabled; it improves processing speed 4-5 times<br>
 -the PPP link is on tty1 (=SMC2) defined as TERMIOS<br>
 -19200 or higher speeds (38400, 57600)<br>
 -modems are 33.6Kbps, XON/XOFF flow control<br>
 -at 19200 the PPP link comes UP all the time, instruction cache enabled or not<br>
 -IP configuration (IPCP): RTEMS defaults (I did not change the requested parameters)<br>
 -compression (CCP) :no compressions negociated<br>
 -ping works witk 8k+ buffers, instruction cache enabled or not<br>
 -mbuf_bytecount = 256*1024,mbuf_cluster_bytecount = 512*1024 <br>
 -heap=3MB<br>
 -SO_SNDBUF=8222bytes<br>
 -SO_SNDLOWAT=2048<br>
 -SO_SNDTIMEO=1s + 0us<br>
 -send() is allways called from the same thread<br>
<br>
My observations:<br>
 -the few initial short buffers are accepted by send() and received correctly by the PC client<br>
 -the first long 8222bytes buffer passed to send() never makes it completely through the lower layers, <br>
  parts of the buffer are seen on the serial TX for a while (scope), with long pauses (seconds),<br>
  then after 10-20 seconds nothing is sent <br>
 -the TCP/IP receive part seems OK (client application custom KEEPALIVE messages continue to get through)<br>
 -subsequent send() calls for the next buffers return (after 1s normally) errno=EAGAIN=EWOULDBLOCK="No more processes";<br>
</div>


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


<div>  the serial TX (tried it because RTEMS application initial messages-smaller, 30 or 137bytes-are sent OK all the time) <br>
<br>
I stress on this point: if the client connects through the 100Mbps Ethernet the TCP/IP works OK, instruction cache enabled or not;<br>
TCP/IP also works on the 19200 dialup PPP with instruction cache disabled.<br>
<br>
Can anybody help with a suggestion?</div>


<div>Thanks,<br>
Horia</div>


<div class=AOLPromoFooter>
<HR style="MARGIN-TOP: 10px">
<A href="http://pr.atwola.com/promoclk/100122638x1081283466x1074645346/aol?redir=http%3A%2F%2Fwww%2Eaim%2Ecom%2Ffun%2Fmail%2F" target=_blank><B>Check Out the new free AIM(R) Mail</B></A> -- Unlimited storage and industry-leading spam and email virus protection.<br>
</div>
</div>
</div>
<!-- end of AOLMsgPart_2_d5ead4b6-d847-4ae4-be7f-44089ad47e29 -->