From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LabVIEW 2013 TCP timing lose message

Dear Robert.

the data is correct except that only three messages are sent enstead of four.

Seee the TCP_Prot_20140111.pcapng ‏22 KB file.

 

Kind regards

 

Martin

0 Kudos
Message 11 of 13
(295 Views)

I can't install Wireshark at the moment to look at your PCAP files, but are you sure that your messages are not getting combined into a single packet? If you send multiple small packets with no delay or read between them, the operating system will combine them into a single transmission. If your receiving side cannot properly identify the beginning and end of a message - if it requires that each message be in a separate packet - I would say that is a bug on the receiving side, not the sending side (your LabVIEW code). However, you can change this behavior in LabVIEW for Windows by setting the TCP_NODELAY option, search the NI site for a link to a VI that can do this.

 

Also, a Timed Loop is not a good way to generate a delay. Use a while loop with timing function. The timed loop that appears to have nothing in it in the TCP Start Stream image is particularly bad and quite likely generates a lot of overhead relative to its value, since Timed Loops run in a separate thread priority.

 

If you must use an empty timed loop like that, use shift registers rather than tunnels to pass the wires through. However, a more standard way to add a short delay is a single frame of a sequence structure with a wait inside it.

0 Kudos
Message 12 of 13
(285 Views)

Dear nathaned,

 

- Yes I'a sure that the mshs aren't combined

- Yes it's a work around

- Yes I have sean that the timed stuvture and time loop are not as acurate as I wouls like to see it.

- Yes I'm sure that the LV code is OK because I gave inverstigated the Wireshark files and I have sean the timestapms

 

The problem is eather Windooooze ider the TCP stack.

And in my case it may be that I'm facing an TCP_nogelay or nagle problem in the Windows TCP implentation.

It seams like the last message will be delaied.

This can be caused by the nagle algorithm that is delaying the package because ir's waiting for a full RCP package.

Where full means one or more kB of data.

 

Best regards

 

Martin

0 Kudos
Message 13 of 13
(268 Views)