TCP/IP large data packets sending problem

[AndyN]

Hello, 

I am sending data chunks of 11kB at the rate of 60 Hz from a RT V to Windows Labview.

The code is fully parallel so the loop receiving the data is only occupied with receiving and nothing else.

Every now and then, it can be in periods of 10 min or 20 min or 40 min the connection will break and the transmission will stop.

I tried it with several computers running XP and Win7 and the same phenomena happens over and over.

Has anybody seen anything like that?

Additional facts:

The flow is: packet of 4B and 11KB, 4B 11KB....

The sending side sends it exactly 1/60s and has no issues with it.

I tried with data chunks of 5-6KB and the same thing happens.

The communication is over Wi-fi.

There are no known issues with Wi-fi.

The sending side reports a timeout - packet was not received/acknowledged .

The receiving side reports a timeout on exactly the same packet - I numbered them.

The receiving side receives most of the time but not always a partial packet - 5KB form the 11KB and never the rest.

I am aware of the TCP/IP 65KB buffer.

Also aware of the segmentation to roughly 1500B by Labview

Also aware of the TCPIP buffer overflow protection.

The timeouts were set to anything from 400-2000ms

There was no noticeable difference in connection breaks between different timeouts.

The period between two constitutive breaks seems completely random. It can happen in a minute or in a half an hour.

The same RT computer sends out data at the rate of 100-200Hz to another RT computer with data chunks of 100B without any problems or breaks ever.

It is my guess that LV has its own layer of TCPIP over the standard protocol layer although I do not know exactly what it does except the data segmentation.

Going to UDP art this point is not considered.

The CPU is moderately loaded -  up to like 20%

Tested on way faster computer with the same results

Has anybody seen such behavior or have any idea what could be the problem? Suggestions?

LV2012 f3 2.4GHz quad core on both ends

[Mark_Yedinak]

LabVIEW is using the OS's TCP stack. It doesn't do anything special with the connection. Have you tried using the wired LAN on the receiving computer? There are LOTS of things that can cause problems with a WiFi connection that can result in a larger latency between packets. For an experiment trying setting your timeout to something large like 30 to 60 seconds. See if the problems still occurs. What type of access point are you using? How is it configured? What security?

[AndyN]

Hello,

I do not remember trying wired connection- did too many tests to remember. I will try that.

The network is a private network with traffic only for this application.

Currently it is N standard with a dlink wireless router and dlink wireless adapter.

LV RT is wired to the router and the receiver has the wi-fi adapter.

The router runs the newest firmware.

Different router was used with updated firmware with the same results.

The system was run with G standard with the same results

The encryption was WPA and WPA2 with the same results.

The RT side is a PC turned into LV RT system.

I used to Linux where I have been informed that I have to handle partial sends by myself.

TCPIP does not send data packets bigger than 1500B.

Every packet is a partial send for me.

I have seen on this forum posts claiming that old LV was not handling partial sends itself till like 7-8.5 ish.

Since the RT is made by LV it is my best guess that it DOES something to the packets in order to keep them flying below 1500B.

Based on the forum search it seems it does it anyway RT OS or not.

[AndyN]

Also the connection shows 100% strength all the time (bars of whatever you call it).

The ping is below 1ms.

[Mark_Yedinak]

The maximum size packet on most Ethernet networks is 1518. With packet headers the maximum TCP data size is 1460 bytes. You really don't need to worry about the fragmentation since the TCP stack handles that for you. It is defined in the protocol itself. When using a wireless network you could run into interferance issues as well. You need to check it when using a wired connection. It would also help if you posted the code used for sending and receiving the data.

One last thing which you may not be able to do is do a network trace. It is a bit trickier when trying to capture wireless data. The trace would be useful to see what is happening on the network.

[AndyN]

Here is the sending and receiving code. 

What is the decision maker when it comes to splitting 11kB into 1460B ? 

[Mark_Yedinak]

---

@AndyN wrote:

Here is the sending and receiving code. 

What is the decision maker when it comes to splitting 11kB into 1460B ? 

---

The packet size is set by the network itself. The default size for Ethernet is 1518. Jumbo frames can be used but most consumer grade equipment which you are using don't support it. The TCP/IP protocols also affect the data size. The packet you get is the source and destination addresses plus a 2 byte type field and a 32 bit CRC at the end. This is the Ethernet frame. The IP header contains 20 bytes. The TCP header is also 20 bytes (assuming no options which is the normal case). So, from that 1518 bytes you need remove the packet overhead to determine the actual data size of a packet. Data length = 1518 - 12 (source/destination addresses) - 2 (type) - 20 (IP Header) - 20 (TCP header) - 4 (CRC) = 1460. The TCP read is only returning the data portion of the packet. All the other stuff is been removed by the stack.

Your code is performing arbitrary reads of the data. A better method would be to have your send send 4 bytes in the front of the data indicating number of bytes of data following. Then read that number of bytes. THat would keep you in sycn much better.

[AndyN]

I know the details of the header and such.

I know the 1460 number and well as that TCP returns only the data portion.

I though it was clear... I know wikipedia.

 My question was in a case of 11kB of single data portion is the 11kB passed straight to the TCPIP layer or LV cuts is into 1460B pices on its own and the passes to TCPIP?

No, my code is NOT doing any arbitrary data reads. This is rude. If you really looked at it, it actually does have the 4bytes at the front followed by the real frame.

I also mantioned it in the first post. Did you read it?

[nathand]

---

@AndyN wrote:

 My question was in a case of 11kB of single data portion is the 11kB passed straight to the TCPIP layer or LV cuts is into 1460B pices on its own and the passes to TCPIP?

---

LabVIEW is calling the underlying operating system functions without modifying the data. The network stack is responsible for breaking up the packets before sending and for reassembling them once received. Remember, that 1460 value is not absolute - the network could use some smaller maximum segment size (MSS) or Maximum Transmission Unit (MTU) that would reduce the number of bytes per packet, and there's no reason for LabVIEW, nor any higher-level application, to know about that.

[AndyN]

Thanks Nathan,

Yes, I am aware well aware that the 1460 is the maximum value and can be further downsized if the network requires it.

In my case though it is pretty much max all the time.

Since LV does not do anything with it and TCPIP is data lossless how is it happening it losses packets in my case?