Slow TCP performance on cRIO

[RGSchmidt]

I am running LV 8.0.1 of a cRIO controller. I have measured a 54ms delay in transmitting a TCP/IP packet to another machine.

This was initially seen by communicating with a standalone single board computer that echoed back a 4 byte packet.

I then created a Windows application in LV to retransmit the received message (4 bytes in length) from the cRIO to the cRIO and measured the round trip transmit time. The time was 54ms.

I then ran both programs on the cRIO sender and retransmitter and measured a round trip transfer time of 108ms.

I then ran both programs on the PC and measured a round trip transfer time of 1ms.

I can ping the cRIO from the PC and get an average transmit time of 1ms. I know that the ping mechanism is much closer to the hardware layer than the TCP/IP stack implemented on the cRIO but used this to verify that there were no detectable problems with the switch. I also used different switches from multiple vendors to verify my transfer times. They we always the same regardless of the switch used.

I used the same calls in LV (TCP Listen and TCP Open Connection) so that I was using the same TCP/IP stack. Evidently the cRIO TCP/IP stack is not as efficient.

I tried going into MAX and changing the TCP/IP settings from "Advanced Ethernet Settings" but was unable to change the "Media Mode" from Autonegotiate. The "Packet Detection" was set to Interrupt but was also not changeable.

Are there any switches availabel to speed up the transfer, similar to turning Nagle encoding on/off on the PC? Are there other alternatives (still need to use Ethernet cable)?

I need to significantly reduce the TCP/IP time. The TCP/IP time is more than twice my calculation time.

Any help is appreciated.

[Bassett_Hound]

Hi RGSchmidt,

Several factors influence the maximum transfer rate between two networked devices, including network topology, types of network interfaces used, various operating systems, ambient network noise/traffic so there will always be a little difference from one network to another.

Would it be possible for you to provide a little more information about your setup and possibly the code you used to benchmark the 54ms delay?  Which cRIO controller are you using?

I have attached some TCP/IP code I have used in the past for profiling TCP/IP. 

Looking to help out,

Steven B.

[CS]

RGSchmidt,

I am seeing similar results for the cRIO.  I have a TCP-host running under LV and windows XP that connects to multiple TCP- targets.  I have connected to several different types of targets and done timing test.  I have connected to another windows XP computer, a LVRT- ETOS desktop computer, and to cRIO devices.  The cRIO device had the slowest response time.  I believe that part of this is due to processing horse power of the cRIO. 

I was able to get my round trip time down to 20mS by trimming down my TCP-host and TCP-Target code.  I noticed as I added loops to the cRIO code that the execution time increased.  This is probably because of the priority of the loops that were added.  The new loops take higher priority than the TCP-target communications loop.

Were you able to determine any resolutions to your problem?

Regards,

Chad

[RGSchmidt]

I was able to reduce the latency to 4ms by parsing the messages as they came in and NOT using the CR/LF termination option. I have 7 control loops within the cRIO and the latency is always 4ms once I reverted to the default conditions on the read. The LV code seems to be very inefficient when searching for a CR/LF before passing the message on. In my case, the CR/LF was the delimiter for the command code for the received message.

[CS]

Thanks for the update.

Just to clarify.  The 20mS time is for 50 bytes wirtten from host and read by target.  Then 100 bytes written by the target and read by the host.