9188 200msec delay

[Bigredd0087]

Hello, I am reading analog voltages from a 9239. I have set the scan rate to 2kHz and I am reading every 20 samples. If I use a 9178 cDAQ chassis the code works perfectly with every 20 samples arriving approximately 10msec apart. If I use a 9188 cDAQ chassis there is a 200msec delay, then a bunch of packets arrive in less than 1msec each and then another 200msec delay and so on. I have switched out every component of the system (9188 chassis, ethernet switch, computer, operating system, DaqMX version, 9188 firmware version) and the problem still exists. I have also tried changing the sample rate and the number of samples read at one time and the 200msec delay is still there. Does the 9188 driver buffer a certain number of points before returning data?

[BrianS1]

Hi Bigredd0087,

I believe the behavior you're seeing is Nagle's Algorithm (http://en.wikipedia.org/wiki/Nagle's_algorithm) in action, which is enabled on Ethernet cDAQ devices to optimize network throughput.  The 9188 will indeed wait until it has enough data to fill a packet (~1500 bytes = 18.75 read()'s of 20 samples each (1500 bytes / (20 samples * 4 bytes/sample) ) before sending that data back to your PC, so this behavior is expected for the input task you describe, and does not indicate that anything is wrong with your hardware.

Currently there is no way for you to disable this behavior on the 9188.  If the 200ms delays are a problem for your application, you could make a product suggestion at http://digital.ni.com/applications/psc.nsf/default?OpenForm that Nagle's Algorithm be configurable on the 9188.

In the meantime, if you want to work around the delays, I would suggest that you increase the number of channels you are acquiring from (even if you throw away their data), and/or increase the sample rate of your task (the 9239 can go up to 50kS/s).  These strategies will increase the rate that the 9188's packet buffer fills, and packets will be sent more often as a result.

Regards,

Brian S.

Software Engineer

National Instruments

[Bigredd0087]

Hey Brian, thanks for the info. I actually discovered Nagle's algorithm right after posting the question. I found a registry edit online that turns Nagle's algorithm off on Windows machines and that fixed the problem.

[LV_Tim]

Do you mind sharing the settings you found that switch off Nagle's algorithm.

[labview4steve]

Its interesting that wikipedia says:
"In generally, since Nagle's algorithm is only a defense against careless applications, it will not benefit a carefully written application that takes proper care of buffering; the algorithm has either no effect, or negative effect on the application."

It seems that ni haven't designed the chassis properly because once you disable this it works how it should....

The 2 terms that make the biggest difference are TCPNoDelay (which is the nagles algorithm) and TcpAckFrequency (which conflicts with nagles algorithim directly)

These can be edited in the registry of windows.

1. To get into the registry editor, go to Start > Run > Type: regedit

2. Browse to: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces

Here you will see your network interface devices listed as random characters.  The only way to really identify which one you want to modify is to click on each one and search for your IP configuration information in the right pane (ie. IPAddress > 192.168.0.100).
It should be the one with the most information in it....

3. Create the two names above as a 32bit D word

right-click the interface in the left pane and go to New > DWORD (32-bit) Value.

Name the first one "TcpAckFrequency" (case sensitive).
Name the second one "TCPNoDelay" (again, case sensitive).

double click on each word after you have made it and enter 1

then restart the machine

you will see a world of difference if you are trying to do realtime control (ie turning stuff on and off at certain times) and not just acquiring data in a buffer..

[LV_Tim]

Thanks for that, it fixed my problem

[Tom_W_[DE]]

Hi Steve-

Thanks for the comments and tips to tune the system for this specific use-case.

I would like to comment on your assessment of the device behavior.  The default setting (Nagle's algorithm enabled) is enabled by default on a wide variety of devices, including Windows PCs and the cDAQ chassis, because it helps reduce unnecessary network stress and traffic and in general leads to better overall performance.  For example, high bandwidth streaming applications (the primary intended application for network cDAQ chassis) are well-served by using the default settings.

An ethernet- or USB-based cDAQ system is not intended for quick single-point control applications, so while making these Nagle's-related changes might improve performance some in those areas, it will lead to increased network traffic (and perhaps decreased performance for other devices on your network) and will still not lead to true deterministic performance for control-system-oriented applications.

If these settings help anyone achieve the desired performance with their cDAQ chassis then they should be used as needed.  But if quick turnaround for slow streaming or deterministic single-point operations are needed then I might suggest another NI platform for realtime control like PXI or CompactRIO.

Either way, I'm glad to hear that you are all able to achieve better results with Steve's advice.  Thanks again for posting-

[yoyo12345]

This sounds exactly like the problem that I am having, although I am using the cDAQ-9188 to write data. Usually the new values are sent to the DAQ every ~20ms but every 10 seconds it suddenly takes 200ms.

I was trying to do the steps that Steve explained but I couldn't find the correct IP. Is it the one that I can see in the Measurement & Automation Explorer? And when I tried to add a DWORD to any of those that were there it said that it cannot create the value ("error writing to the registry")

Any help would be appreciated!