LV2013, Win7, LVRT 2013, PXI 8196 Controller I've been using TCP to talk to a PXI box on this project for years. It's been fine. Doing a rework and thought I would investigate other options. This Doc says: "Network streams are a LabVIEW feature released in LabVIEW 2010 designed to provide efficient data streaming. They provide easy to use higher level abstractions to handle connections, disconnections, and data flow control, while still maintaining similar throughput of raw TCP/UDP." So I decided to compare them. For TCP, I made a PXI program to receive N bytes, and echo it back to the host. The host simply sends an N-byte message and waits for the reply. It measures the time taken for 5000 round trips, and computes the Round Trips per second value. I found that for N = 1, 4, 16, 64, 128, the speed varies very little: N Speed 001 2321 004 2322 016 2316 064 2336 128 2308 256 2095 512 1170 1024 924 2048 723 This makes sense: the TCP overhead dominates for small messages. With larger messages, the actual transmit/receive time dominates. Still that's 2300 ROUND TRIPS per second - about 400 uSec per loop. So, I did the same test with DataStreams. But since DataStreams are unidirectional, I created TWO streams, one in each direction. The PXI end reads and echoes a message; the host transmits a message and waits for a reply, and times the whole thing. Y U C K N Speed 001 66.6 002 50 004 50.05 016 50 064 49.96 128 50 256 49.66 512 46.17 1024 40.02 2048 33.4 Now, there's no way that qualifies as "maintaining similar throughput" in my book. that's 46 times the speed (2300/50) ! Am I missing something? Attached is a project with both versions, both ends, if you care to look.

I think you're confusing "throughput" and "latency." Throughput is measured in bytes/second, not round-trips per second. See http://www.ni.com/white-paper/12267/en/. NI's performance data show that Network Streams do have higher latency than TCP, although not as bad as your test. That document provides suggestions on how to reduce latency in Network Streams, which you may want to try if you haven't already done so. EDIT: what you can do to speed that up is to add a Flush with a 0 timeout after each write (per the above-linked document).

LabVIEW

Datastream = dog slow ... why?

Solved!

@CoastalMaineBird wrote:

Back to a quiet network today, and I still can't get above 1350 round trips/sec.

Looks consistent with NI's reported performance - in the document I linked, there is a table showing that network streams have 2-4x longer latency versus TCP.

CoastalMaineBird wrote:

Still looks like DataStreams are a cut below the basic TCP. And given that you have to do this finagling to get performance, the claim of "easier to use" or "less complicated" is dubious.

I haven't used network streams, but my impression is they would be better suited to an application where you want to stream data in one direction as fast as possible without worrying about buffering and connection details, than they are to a command-reply messaging system which it sounds like is what you have.