Datastream = dog slow ... why?

[CoastalMaineBird]

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.

[billko]

If you have to ask a question, that means it's time for me to learn something new.  🙂

[CoastalMaineBird]

For the record, using a data type of ARRAY of I32 (instead of STRING) makes no significant difference in performance.

The doc references above says "This means the sender must flatten all data to a string and the receiver must unflatten the data from string. This adds an extra layer of complexity to non-string data transmission."  I thought that might make a difference, but no.

I'll take the extra "complication", rather than pay such a huge speed penalty.

[CoastalMaineBird]

UDP operates just a tad slower than TCP, but in the same ballpark.

N       Speed

128    2288

So, either I'm missing something, or DataStreams are a real dog.

Somebody convince me.

[CoastalMaineBird]

Attached is a newer version of the project, with four versions (TCP, UDP, DataStream STR, DataStream [I32]).

Here's the DataStream code. the PXI simply waits for a message and echoes it back. Don't know what I could do to speed that up.

[nathand · Accepted solution]

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).

[CoastalMaineBird]

Well, the paper you linked to says this:

"Network streams are an easy-to-configure, tightly integrated, and dynamic communication method for transferring data from one application to another with throughput and latency characteristics that are comparable with TCP."

Regardless of the exact nomenclature, I am measuring the same thing (or attempting to), for both TCP and DataStreams.  Yet the results are vastly different (2300 vs 50).

[CoastalMaineBird]

OK, so you nailed it !

Now the number is 5555, rather than 50 !

Attached is a new library with a FLUSH version.

Now my question is, how did they get FASTER than TCP?

[CoastalMaineBird]

Hmmm.  After playing with the TCP version for a bit, I went back to the DataStreams version and I can't get those good numbers anymore.

Now I get speeds around 1200.

[CoastalMaineBird]

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

Still, that's a vast improvement over the 50 I was getting before.

Thanks, NathanD

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.