Speed Limits for Data Acquisition and Transfer Via TCP

[FLng]

Project description:  Acquire data (using PXI-6229 DAQ with a PXI-8104 Embedded Controller that has LabVIEW RT operating system) and send the data using TCP packets.  The current project requires the TCP packets to be received (by another computer) at 1kHz, but we would also like to benchmark the system (determine its limits).

Here are some questions (for now let's assume the computer receiving the data packets does not limit the speed of the system):

1) What are the bottlenecks?  Is it the DAQmx Read.vi? The TCP Write.vi? Or something else?

2) At what speeds might I expect the TCP data packets to get to the reciever (assuming no delays due to distance)?

3) How can I increase the speed?

Also, any general suggestions/pitfalls would also be appreciated.

[JK1]

Hi,

Few suggestions to your queries:

1. 1Khz rate is easily achievable using the configuration you have given.  There are no bottle necks with DAQmx drivers.  While developing the DAQ loop take care that you read the samples as quick as possible. 

i.e if your rate is 1KS/s read the data at 100Sample intervals that is 100ms once, you will get 1000 samples in 10 iterations (100mSEC * 10 = 1Sec).  if you transfer 100mSec data over TCP it will not be a much load to both transmission and receiving block.If you choose to read samples at 1Sec interval it increases the amount of data that is pumped into TCP per sec.

I generally prefer "low amount of data:faster loop rate: when compared to "large amount of data:slower loop rate"

2. While transferring data through TCP do not right data more that 5KB in a single data write. If you have large block of data break them into small fragments and write in multiple TCP writes which will give a consistent deterministic data transfer.

3. When large samples are transferred the receiving loop (main receiving loop) should not do any operation like scaling, analysis etc., it is better to queue the data and do those operation in other parallel loop which will not affect the TCP determinism.

Post back for queries.

[JK1]

Adding to the above (about the vi you have posted):

1. Do not transfer data into TCP in same loop. when no. of channels are low then this will not be a trouble.  When no. of channels increases then the performance gets affected.

2. Queue the data from daqmx into a queue.  and dequue the q in parallel loop and then transfer via TCP.

Its ideal to use parallel loop and a queue architecture.

Post back for queries

[Ben]

JK gave some good suggestions. Please concider them closely.

The bottle-neck is the network and access to it.

If it is at all possible, make it an issolated network so that only your transfers use the network.

The last time I worked with someone benchmarking ethernet transfers, the max transfer rate was achieved when the packet sized matched the ethernet packet size of (????) 64K?

The Naegel Alogoritm also comes into play so watch for that.

Determinism of transfers across an ethernet network is just a pipe dream unless you have complete control over everything that sits on the network AND you ensure that no two nodes attempt to transmit at teh same time ( Collision,,, random delay,,,, retry is hardly determinisitic).

I have experience with a set of hardware where I utilized a SCRAMNet GT (Shared Common RAM  net from Curtiss-Wright) network and all of the top of the line timing and syncronization hardware from NI (ther was much rejoicing in Austin when we placed that order I'll tell you!). I am not at liberty to reveal the results but I can tell you that closing a loop over the ethernet is not a trivial task. NI does have a deterministic network that takes over the network interface and implements time slices to ensure no collisions. You may als want to look into that.

Ben

[FLng]

1) Thanks for the responses.  I'm also new to this area, so any corrections or help is greatly appreciated.

2) Here is some more info about what I'm trying to do.  The network consists of the NI PXI chassis (w/ embedded controller & DAQ) and a direct ethernet connection to another computer acting as the server.  The goal is to make this system "real-time" so I've been instructed to take a sample (of all channels shown in the vi attached w/ first message) and send it out immediately in a 32-byte TCP data packet (I believe this is the minimum size).  So, I would have to present a serious argument to coworkers to store any sampled data in a queue.  Any suggestions of other ways to do this would be interesting.

3) Not included in the vi attached above, I also need to read TCP packets from the server.  Is it better to open another connection w/ a different port? Is it ok to use one connection to send/recieve TCP packets or will this cause some problems?

4) If the server is not reading the TCP packets fast enough, I'm guessing this will bottleneck the system.  Any info on what happens when the server is not ready the TCP packets as fast as my NI system is sending them?

[FLng]

Re: message 2 section 1

You mentioned reading 100 sample intervals.  Can you explain this a little?  I was thinking I could just continuously collect samples.

[FLng]

In case it helps, the server computer is a VG5.

[Ben]

---

FLng wrote:

1) Thanks for the responses.  I'm also new to this area, so any corrections or help is greatly appreciated.

2) Here is some more info about what I'm trying to do.  The network consists of the NI PXI chassis (w/ embedded controller & DAQ) and a direct ethernet connection to another computer acting as the server.  The goal is to make this system "real-time" so I've been instructed to take a sample (of all channels shown in the vi attached w/ first message) and send it out immediately in a 32-byte TCP data packet (I believe this is the minimum size).  So, I would have to present a serious argument to coworkers to store any sampled data in a queue.  Any suggestions of other ways to do this would be interesting.

3) Not included in the vi attached above, I also need to read TCP packets from the server.  Is it better to open another connection w/ a different port? Is it ok to use one connection to send/recieve TCP packets or will this cause some problems?

4) If the server is not reading the TCP packets fast enough, I'm guessing this will bottleneck the system.  Any info on what happens when the server is not ready the TCP packets as fast as my NI system is sending them?

---

You are listing more reasons for you to contact your local NI rep and ask them about Deterministic Ethernet. it will help with your bidirectional packets.

RE#4 Targt not keeping up...

TCP/IP has guarenteed delivery built-in. No packets SHOULD be concidered delivered until the reciever ACKs the the packet. If the server does not ACK, the I/O SHOULD be re-try by the sender.

So....

Start by looking into the Off-the shelf Determinisitc Ethernet.

And if you really want it to go fast and reliably then check SCRAMNet*. Update to the memory on one machine are seen on all of the other machines within nano-seconds (or was that femto-seconds?).

Ben

* Warning: not cheap. Each computer will cost between $3-5K. Redundant self healing switches will run you about $30K.