daqmx c# high processor usage

[Kreuters]

hey

i have recently purchased Measurement Studio 8.1, and for my first application i created a very simple DAQmx continuous AI program using the DAQmx wizard, with a sample rate of 100k and reading 10k samples at a time. the application runs fine, but the processor usage is very high, around 50%, where an identical program created in labview with the DAQmx wizard has a processor usage of ~5%.

i have seen another thread <a href="http://forums.ni.com/ni/search?board_id=232&submitted=true&q=c%23+processor+usage">here</a> with the same problem, but this was solved by compiling without the debugger. i do not find that this helps in my case.

does anyone know how to fix this?

using DAQmx 8.3 incidentally.

[JonBowers]

Hi Kreuters,

What version of C# are you using (2003, 2005, express)? You say you have tried running the app by hitting Ctrl+F5 (or go to Debug >> Start Without debugging) and it still uses 50% of the CPU?

Regards

Jon B
Applciations Engineer
NI UK & Ireland

[Kreuters]

I am using visual studio 2005, and yes, running with Ctrl+F5 (or selecting 'Run without debugging' from the menu) does not solve the problem, same processor usage in both situations.

[JonBowers]

Hi again,

I am going to try and reproduce this. Can you verify that the problem still exists when running one of the examples. "C:\Program Files\National Instruments\MeasurementStudioVS2005\DotNET\Examples\DAQmx\Analog In\Measure Voltage\AcqVoltageSamples_IntClk\Cs" would be a good choice.

Regards

Jon B
Applications Engineer
NI UK & Ireland

[JonBowers]

Hi again,

Running the ContAcqVoltageSamples_IntClk example with debugging enabled I get around 10-15% CPU usage on a Dual core Intel chip @ 2.13Ghz with 2GB RAM and a PCI-6251. I ran the acquisition at 100K reading 10K samples each time. With debugging disabled it uses between 2 and 6% CPU.

What are the specs of your computer and what data acquisition card are you using?

Regards

Jon B
Applications Engineer
NI UK & Ireland

[Kreuters]

the development machine is an athlon xp 2800 i think, and the DAQ card is a 6062e (simulated on the development machine, probably should have mentioned that earlier)

i am afraid i cannot test that example right now, i am out of the office for until friday, will check it then.

[Kreuters]

hey jon

i have tried the example as suggested, and i get very similar results, 2-7% processor use without debugging, 16% with.

when i create a new NI DAQ application however, the problem still remains, 41-50% processor usage with debugging enabled and 41-47% usage with no debugging. this is acquiring at 100k reading 10k samples each time, and plotting them on a graph with no autoscaling.

what is causing this high processor usage, is it because the DAQ card is simulated? i suppose not, if loading the previous example gives normal processor usage figures.

any ideas?

[JonBowers]

I think the extra overhead is probably just plotting the data to the graph. Can you post the code you are using so I can run it on my machine?

Regards

Jon B
Applications Engineer
NI UK & Ireland

[Kreuters]

the code is simply what is created with the DAQ assistant wizrd in Visual Studio.

i have zipped it up and attached it.

seems unfortunate that the processor usage would be so high using .NET, when i can execute the same code in native Labview with < 10% processor usage. makes it a pretty non-desirable development choice.

[bilalD]

I'm not sure how you are seeing the LV app with less than 10% CP usage, but when I compared a LV app with the example you attached, it looks like the additional overhead you are seeing is happening due to the graph control in .NET. If you comment out the graph part, the CPU usage matches up with the LV apps. I created a VI with the same acquisition parameters as the .NET app using the DAQ Assistant. So the .NET and LV DAQ APIs are comparable in terms of performance, but it seems the .NET graph has a little more overhead than the LV graph.

We are always working on improving the performance of the .NET graph. The .NET graph is written using gdi+ (.NET Drawing API), which unlike gdi (which is what the LV is based on) does not use hardware acceleration. So this just means the CPU had to work a little harder and cant pass off as much work to the GPU. You will see better graphing performance (less CPU and memory usage) as the .NET drawing API starts making more use of HW acceleration. Plus we are always working on ways to further optimize the graphs.

This should not affect your aquisition rates since all of the data is clocked in by the hardware. DAQmx 8.3 uses DMA by default for all its buffer transfers to keep the CPU usage to a minimum (as much as is possible) so it should keep the CPU available for any extra processing it might have to do without necessarily affecting the acquisition rate too much.

I hope this explains things.