DAQmx AI read at 2MS/s results in high CPU usage

[doy]

I have an application that reads 32 channels of analog input signals at 2MS/s, simultaneously. The actual hardware will be: PXIe-8135 Win7, PXIe-1071 chassis, 2x PXIe-6368 (16 channels). The two PXIe-6368 will provide 32 channels data acquisition.

I don't have the hardware at this moment, but I've been estimating the CPU requirement on alternative set-ups, as I have concerns on CPU usage at high speed data acquisition. The two alternative set-ups are:

1) PXIe-8133 (quad core) WinXP, PXIe-1062Q, PXI-6133. 

2) PXI-8106 (dual core) WinXP, PXI-1042, PXI-6133. 

Note: PXI-6133 supports high speed AI at 2MS/s, simultaneously.

I've writen a simple continous data acquisition software to allow me to benchmark the CPU usage. The sampling rate and the number of channels are configurable. What I found is:

1) at low sampling rate, e.g. 100 kS/s, the CPU usage is minimal on both set-ups (dual core or quad core), no matter the number of channels is 1 or 8. The CPU reading was about 1-4%

2) at high sampling rate, e.g. 2MS/s, regardless of the number of channels being used, be it 1 or 8, the CPU usage was 50% for dual core, and 25% for the quad core, ie. a full core was fully used.

3) the transition from the low CPU usage (<5%) to high CPU usage (>45%) when the sampling rate increases is fairly steep and shows interesting channel-dependency (note the following was obtained with a dual core controller PXI-8106).

• @1 channel, it happened between 950k to 970k,
• @2 channels, it happened between 470k to 480k
• @4 channels, it happened between 230k to 240k,
• @8 channels, it happened between 120k to 130k,

This pattern reminds me of buffer length related issue but I double checked a sufficient length of buffer was used. It also suggests, some surprising congestion has happened when the amount of data increases to certain level.

My question is, is it a problem with this particular board (PXI-6133), or the DAQmx driver (9.5.5f4). How badly the problem is when I'm actually doing a 32-channel acquisition?

For your information, I've attached the benchmarking software.

Thanks!

Donghui Yin

[doy]

Just want to follow up ... Taskmgr showed that most of the CPU usage was kernel related. This means it has nothing to do with how I programmed the software; the bottleneck happened at the driver software or hardware level.

[doy · Accepted solution]

I followed this example code (see link below) and used event-based DAQmx, now the excessive CPU usage problem has been resolved. The CPU reading is now less than 10%, whereas it could be 50% (dual core case) or 25% (quad core case) at the same sampling rate and the number of channels.

http://zone.ni.com/devzone/cda/epd/p/id/5911