Re: Degradation of TCP connection

Yes vxworks does have it's own network data buffers that eventually
can cause problems. I am having a similar issue with vxWorks TCP and
can share what I've been doing to try and diagnose it in the event it
gives you some ideas.

My application requires sending tons of data at very fast rates over a
Gigabit ethernet. Essentially I am trying to send 4,800,000 bytes per
second (this may prove unfeasible). Anyways, what I do is read voltage
samples off an A/D card connected to my Single Board computer via the
PC104-Plus interface, at a rate of 400k samples per second for 6
channels. Each sample has 16 bits, or 2 bytes of data. However, the A/
D card's data buffer can only hold about 64K samples worth of data
before overflowing, so I need to make sure I am taking data off the A/
D card at a constant rate and then sending that data out in large
packets over the ethernet.

After 6000 samples accumulate in the data buffer, I have a PCI
interrupt trip which copies the sample data off the PCI buffer and
into another buffer, then sends a message to my ethernet application
telling it to send the data on the second buffer out over the TCP
socket.

My connection keeps up fine for the first 10 or so interrupt cycles,
then the network write task begins falling behind. After some
troubleshooting, I determined that after sending about 128k bytes out
over the TCP socket, my problems start. The same holds true when I did
a test with UDP (just to verify that it wasn't the receive side
causing the issue). If I shrink the packets, or send less data at a
time, I still eventually run into the same problem at 128kbytes every
time.

The issue seems to be (just a theory right now) that the vxworks
network data buffer has filled up at this point and needs to free the
memory and re-initialize, so the tNetTask is pending and my network
send call has to wait. The 128k-bytes total seems to match up with the
default network memory block total. I am trying a new method using
something called the zbufSocket Library. This library basically allows
you to send data over a socket without using vxwork's network data
buffer. However, WindRiver took zBuf support out of vxworks version
6.5, so I am wondering whether this is a dead end.

Try this link http://slac.stanford.edu/exp/glast/flight/sw/vxdocs/vxworks/netguide/c-tcpip.html
and go to section "4.3.3 Network Memory Pool Configuration". This
covers how the network memory is set up. I am still trying to digest
some of it myself to get a better idea. There does appear to be some
way to diagnose network memory usage.


If I come across something, I'll post a better update.
.

Relevant Pages

  • Re: Slow vxWorks boot - shared memory related?
    ... it was due to no network being connected. ... We've used the vxWorks shared memory routines ... > Attaching shared memory objects at 0x4100... ...
    (comp.os.vxworks)
  • Re: network stack
    ... I do not belive Microsoft use VxWorks. ... can use a TCP/IP stack. ... >> with a bit higher priority than the original tNetTask. ... >>>network interfaces to be of a higher priority than the other network ...
    (comp.os.vxworks)
  • Question on Implementing END
    ... Currently i am only concern on establishing an END driver attach to ... VxWorks will display my END) ... Currently i dont have a board with BSP ready. ... simpc is not Network ready.. ...
    (comp.os.vxworks)
  • Re: Undefined references to networking libraries when compiling bootable images
    ... Check if the Vxworks network components are included in your Tornado ... go to the "VxWorks" tab (you have three tabs: ...
    (comp.os.vxworks)