Real-Time Measurement and Control

cancel
Showing results for 
Search instead for 
Did you mean: 

Onboard device memory overflow

Hi, I’m getting error -200361 from my cDAQ-9188 “Onboard device memory overflow. Because of system and/or bus-bandwidth limitations, the driver could not read data from the device fast enough to keep up with the device throughput. Reduce the sample rate, or reduce the number of programs your computer is executing concurrently”

I’m trying to acquire 12 channels from three NI9222 modules at 500 kS/chan.

I’ve a gigabit network card, a gigabit switch and nothing else connected to these. Lights indicate that all components are running at gigabit speed.

Have also followed advice at http://digital.ni.com/public.nsf/allkb/7BF7DE5ECD4081C7862577A00075E048

Am not doing any downstream processing of the data, and CPU usage in Windows taskmanager is very low.

Works ok at 400ks/sec, reasonable at 450 and hardly at all at 500ks/sec.

Am I approaching some fundamental limit of what the cDAQ-9188 is capable of or should I keep fiddling with buffer sizes / get a faster PC, etc ?

 

0 Kudos
Message 1 of 6
(5,787 Views)

Hi dmgill,

 

Thank you for your post and welcome to the forums! This is an interesting problem.The maximum sampling rates of the 9222 modules are 500Ks per channel, so theoretically there should be no problem with the hardware itself, as the error message suggests.

 

Have you tried reducing the amount of channels you are sampling? I would suggest trying one channel at 500 Ks and see if the error ocurrs. Is it possible for you to upload your code?

 

Currently if you are running 12 channels each at 500Ks, if each point is a double (64bits) the throughput of the system is around 48MB/s. Added to that there is the TCP/IP overhead, however the gigabit ethernet should easily cope with this application. The theoretical limit of gigabit ethernet is 125MB/s.

 

What are the specifications of your computer? Have you checked the network speeds in task manager while running your application?

 

Best Regards,

Ben

Ben B.

Applications Engineer
National Instruments UK & Ireland

"I've looked into the reset button, the science is impossible!"
0 Kudos
Message 2 of 6
(5,775 Views)

Dear Benjimin,

Thaks for support.

In answer to your questions:

 

It seems fine on 10 channels.

 

I'm reading raw data as int16, so the total throughput is around 12 megabytes per second, or just below 100 megabits. this is reflected clearly in the system monitor which is showing about 8.3% Net usage for 10 channels at 500 kHz (10 * 1Mbyte per sec = 80 megabits = 8% of 1 gigabit, so this makes perfect sense).

 

I've uploaded some of my code. I'm afraid this is part of a much larger program so cannot be executed. I've tried dissabling everything which happens to the data once it's in the machine, but this makes no difference. An area you may be able to help with is how I might change line 109 DAQmxCfgInputBuffer(...) and line 149 DAQmxRegisterEveryNSamplesEvent(...). I've tried various buffer lenghts (including leaving it at default) and various everyNSample numbers of samples, but never seem to make a great deal of difference. Is there an optimum setting for these parameters ? If needs, I could recreate this as stand alone. 

 

I am (optionally) also shipping the data back out again over a TCPIP connection to an adjacent machine. when I do this, the network usage doubles (as would be expected). Having this option in my code on or off makes no difference to whether or not it can handle all 12 channels.

 

The machine has an Intel Pentium G840 @ 2.8GHz. 4 GB ram, 64 bit OS, although I'm compiling as 32 bit. Network card is a second card I put in a PCI slot which is a TP-LINK TG-3269 gigabit Ethernet. This part of the network is used for nothing else apart from moving these data around. I use the built in network adapter for internet access.

 

Thanks,

Douglas.

 

0 Kudos
Message 3 of 6
(5,758 Views)

Hi Douglas,

 

Thanks for your reply. The problem seems very much a driver level buffer problem. Having looked further into the 9188 chassis, the original maximum stable throughput is stated to be at 10MB/s, as you are using 3 high speed modules generally this problem is not so apparent. This will be the reason why the internal cDAQ chassis buffer is overflowing, the data from the 9222 modules cannot get the data to the PC fast enough. The KB suggests that more can be squeezed out of the link, one being the jumbo frame which you have tried.

 

There is nothing wrong with the code and you can leave the DAQmxCfgInputBuffer as default. I have a few suggestions to get the most out of the link:

 

- Update to the latest version of DAQmx driver, as these do usually have optimization improvements

- Connect the 9188 directly to your PC, remove the switch. This should not make too much difference however sometimes switches can cause issues

 

The application works fine at 400Ks because the throughput is 9.6MB/s. Hardly at 450Ks as the throughput is 10.8MB/s.

 

Unfortunately you are working at the internal limit of the cDAQ chassis throughput.

 

Best Regards,

Ben

Ben B.

Applications Engineer
National Instruments UK & Ireland

"I've looked into the reset button, the science is impossible!"
0 Kudos
Message 4 of 6
(5,730 Views)

I'm evaluating to use the cDAQ 9188 in order to acquire 4 or 8 channels with the NI-cDAQ 9188 and NI9222 or NI9223.
Ben said that:
...if each point is a double (64bits) the throughput of the system is around 48MB/s...
I thought that each point were a 16bits numbers instead of 64bits; I thought that, the "conversion" from raw data (16bits) to volts (64bits), to happen on the PC side.
So in Ben's hypothesis I can acquire just one channel at 1MS/s or 2 channels at 500kS/s. Is it correct?

 

Best Regards,
Paolo.

0 Kudos
Message 5 of 6
(5,162 Views)

Hi Paolo-

 

The 9223/9222 (and other 16-bit modules for the most part) are all transfered as 2-byte raw samples and then scaled on the host PC, like you suggested.  So, you can expect that a single 9223 with all channels at their maximum rates will require this level of bus bandwidth for data transfer:

 

4 (channels) * (2 bytes/sample) *  1M (samples/sec) = 8e6 B/sec.

 

 

Hopefully this helps-

Tom W
National Instruments
Message 6 of 6
(5,160 Views)