CompactRio TCP_nodelay

[fmnieuwenhuizen]

For the real-time control of a motion simulator I need to send TCP packets of 32 bytes with a CompactRIO 9012. After ample testing we have figured out that the problems we are experiencing are due to the TCP connection using Nagle's algorithm for sending data packets: i.e. stacking smaller packets together and sending them off at the same time, thus delaying them.

On a Windows or Unix operating system one can counteract this behaviour by setting a TCP_nodelay, forcing the socket to send the data the moment it gets it. For the compactRio I have only found this post from 2006:

http://forums.ni.com/ni/board/message?board.id=170&view=by_date_ascending&message.id=188866#M188866

where it is mentioned that there is no TCP_nodelay on the RIO. Is this still the case on the current systems and software? I can hardly believe that this would be the case for a real-time system. Btw, I am using LabView 8.5 with its accompanying modules. 

Would somebody have a way to set TCP_nodelay on the RIO?

Thanks very much for your replies.

[Arnie1]

Hello,

are you using the standard TCP/IP functions in labVIEW?

I also have a time-critical TCP/IP application running on a CRIO 9014 and have used the usual TCP/IP Listen, Read, Write, to communicate with a Win XP host, but have not found any significant delay problems, although maybe my application is not as critical as yours.

[fmnieuwenhuizen]

Hi Arnie1,

I am using the standard TCP/IP functions in Labview. The reason why I am having problems is most probably due to the fact that I am sending 32 bytes (rather small size for a data packet) at 10 ms intervals. The socket seems to be packing data-packets together to send them off all at once with some delay. I really need to get the data out at the 10 ms intervals, otherwise the motion platform will "jump" when it is not receiving data (as it is doing now).

I have been thinking of just sending bigger data packets, in order to try to have Nagle's algorithm send the data right away, but this does not give any guarantees about the sending as it might still try to pack packets together.

If you have any thought, comments or solutions, I would be very happy to hear from you.

[Benoit]

TCP-IP is not a deterministic way to comunicate. I suggest you to use a RS-232 or anything like this to transfert your packet. This will work with system that are not far one to the other. TCP-IP will never guaranty that the packet will not be delayed. There is some propryetary ethernet communication possible, but you will never be able to put it in a standard network.

B.

[fmnieuwenhuizen]

You are very right about that TCP could potentially delay packets, but in practice it seems to work in our environment (dedicated gigabit network, basically 2 computers talking to each other). With UDP communication sending and receiving a packet (32 bytes and 40 bytes resp.) normally happens within 1 ms. With TCP this would probalby also be possible if only one could switch on TCP_nodelay on the CompactRio.

[Arnie1]

Hi,

I's sending very short messages too, of about 8 characters, up to every 50ms. The messages are in reply to received commands so I can tell that they don't arrive back out of sync or joined-up.

But I've not tried to do this as fast as every 10ms.

However, I found in the past, that with CAN-bus  even faster rates are possible without problem.

A.

[jankl]

Hei

This thread has been silent for a long time but I post as this matter still seems to be unresolved.

I asked the question "How to disable Nagle algorithm in cRIO" to NI a long time ago, they did not follow up. My problem was the same as yours, long latency times for a TCP based host-server setup between a PC and the cRIO.

My solution was to use the NODELAY option in winsock as described in this link http://digital.ni.com/public.nsf/allkb/7EFCA5D83B59DFDC86256D60007F5839

this solved the problem on the PC side.

On the cRIO however, I never found a solution. I tried to look for the setsockopt function, knowing that cRIO is based on VxWorks. The idea was to load the function using the call library function as you would do on Linux. But I never found the library.

My solution was to pad the size of the messages from the cRIO up to approximately 1500bytes. This lowered the latency and thereby the efficiency of my system.

-Jan-