TCP/IP Transmission Delay

[madd]

1. Hi i have been working on TCP/IP to identify delay of 200ms for large packet size. i have used No_Delay Tcp/IP function but following are the observations( setup is windows 7 point to point communication between 2x PC's , LabVIEW 2012 and 1G Ethernet interface).

a. No/min delays for small packet size but output on 1G network is very low 192-300Mbps.

b. For large packet size continuous delay of 200ms and above is experienced.

2. There are various discussions on internet about this delay and suggestion to change windows regedit properties(Windows size, DelayACK, AckFrequencyTick e.t.c). When i browse to that folder there are no entries available as default i have to create new. but still it doesn't seem to have any effect on the delay in my VI's 

3. How can i achieve max data rate with no delays for every packet size (Attached are the       Vi's). 

[billko]

What size are we talking about? 

[madd]

Hi  billko

in my Vi you can see that i have a for loop (with 32 value double at shift register) which is generating sample size of 32,64,128,256.........onwards each packet is converted into string and send to receiver iteratively (inner loop) 1000 or more times. Based on that execution time of loop is determined, data rate and delay are calculated. you can run the vi and observe that a delay of 200ms is observed for sample size 8192 and bigger  which is less than or equal to 1ms for small sample size. 

How to avoid this 200ms delay.

Help/ tips to tweak TCP/IP registry settings seems unaffected which i have mentioned in my previous post.

[rolfk]

You're mixing and matching terms and conditions here. Besides, a little nitpick, your smallest packet is 64 samples, not 32, due to the logic in the loop generating the 2^x values.

The TCPNoDelay is only useful if you send small data packets and expect a response from the other side before continuing. For your example this has only minimal influence and in fact a negative one for the small packets since with Nagle enabled the small packets are combined into a bigger one and send off whereas without Nagle each package is send in its own data frame which will cause extra overhead.

Without disabling the Nagle Algorithm (what TCPNoDelay actually does), that small packet sits in the output queue and is only send after 200 ms or so, since sending of small packets is very inefficient, so the TCP socket tries to wait to see if more data can be all combined into a single packet to be send over the wire. Since you only have one way direction (only the server sending data to the client without acknowledgement of the client) that delay doesn't significantly influence your measurement. And you throw so much data at the socket that the Nagle delay never really gets into play since you reich the 1000 bytes or so where Nagle sends off the data anyways within a few microseconds.

So yes when you try to send lots of small packets and each needs to be acknowledged before you go further you do not want to have that delay.disabled, for your measurement however it makes little influence.

I have run it on my local computer, using "localhost" in the client and I see following pattern:

There it starts somewhere around 0.17ms per packet and increases to about 0.23ms for the largest packet. This is what I would expect to happen. The data transfer itself is only a fraction of this time. For small packets the handling of the data buffers (creating the sample buffer, converting to bytes, transferring them into the TCP/IP socket) is the major time spend and a lot of that is pretty independent of the size of the packet.

Morale of the story: If you want to maximize data throughput you need to create large packets and send them off in one go.

Of course my measurements are with localhost so the data never really hits the wire. Windows socket instead transfers data in the loopback device through shared memory, which can go far beyond the 1Gbps limit of modern network adapters if you send large packets. For me it goes up to 8.5Gbps for the largest package.

[madd]

Thank you Rolf Kalbermatter

For a comprehensive explanations. i have tested it also in loop back mode it has shown good results however i have to put my system in a network switch later on so i need o evaluate it with min 2x PC's. here comes the problem the loop back delay for sample size 8192 (Packet size 8192*8 Bytes) is not exceeding 1or 2 ms but in case of point to point (B/W two systems) connection 200ms has been observed quite frequently same is applicable for sample size grater than 8192 with delay also increasing.

i think LabVIEW has nothing to do with this delay it should be some fine tuning of my Windows operating system if any suggestions in this regards to avoid delay are welcome.

[rolfk]

Your test with the loopback mode indeed shows that it is not LabVIEW which does something weird but something in between. Now comes the process of debugging and in this case this means elimination.

Try without switch for once. If that doesn't show any difference (my hunch is that it will however and a hub might not) try to switch the PCs then try with other PCs until you see a significant difference. The magic size of  8192 almost sounds like a Jumbo packet issue except that this is the jumbo packet byte size but you use samples, meaning your data packets are at that point over 65535 bytes (exactly 65540 bytes), which is likely where one of your hardwares has a problem with.