Hyperthreading problem with CDAQ/NI-DAQmx

[Pacsoft]

Hi,

Please take a look at the following problem:

I am using NI-DAQmx 8.6.1 and a CDAQ chassis. My application was written in LabWindows/CVI. The application creates a thread, which in turn loads a DLL using the Win32 LoadLibrary() function, then get pointers to functions defined within the DLL by using the Win32 GetProcAddress() function, and finally I use those pointer to make function calls.

The problem is:

If Hyperthreading is ENABLED, the function calls I make to NI-DAQmx (output/input voltage) run perfectly.

If Hyperthreading is DISABLED, the function calls I mahe to NI-DAQmx  (output/input voltage) take about 60 seconds to return.

As I told you, the root cause is the hyperthreading feature, because as soon as I enable it back, the app runs perfectly. The thing is that I have to run this app in non-hyperthreaded microprocessors as well.

However, if a make the function calls from the main thread, i.e, I make a function call to NI-DAQmx when the user press a button in the main panel, it does not matter if Hyperthreading is enabled or not.

Do you know if there is a workaround by enabling DMA or interrupts for the CDAQ channels ? Or why is this happening ?

Regards

[Mark_E]

Hi Pacsoft,

I apologize for the delay in getting a response posted. So that the community can more fully answer your question, please answer the following questions:

1. What function calls are you making?
2. Which one takes the most time?
3.  What behavior do you see when using a simulated device?

DAQmx does not rely on multithreading so unless some other process is severely starving DAQmx or the USB controller, then you shouldn't be getting this. Once I get some more information, I will go from there to provide you an answer as to what you’re experiencing. Thanks for your patience.

[Pacsoft]

Hi, Mark,

I have not tried with a simulated device. I will try that right away. Regarding DAQmx function calls, those that have access to the CDAQ chassis take a long time to return, about 60 sec. I mean all of them, like DAQmxWriteAnalogScalarF64(), DAQmxWriteAnalogF64(), DAQmxReadAnalogF64(). As I told you, as soon as I enable Hyperthreading, the application works perfect.

We also wrote another application that uses PXI, and we observed that the application crashes (while issuing DAQmx function calls) when Hyperthreading is disabled and runs perfect if it is enabled. From this I think is very clear that Hyperthreading is something that the DAQmx driver is taking for granted.

Regards

[Mark_E]

Hi Pacsoft,

All right, here’s the latest. I tested one of our shipping examples on a machine that has hyperthreading and it seems that the behavior is reproducible on our end when I disable hyperthreading.

The puzzling part is that DAQmx worked in the past on non-hyperthreaded machines. My best theory is that on a machine with hyperthreading capabilities, something in the configuration may still linger around that makes programs attempt to use hyperthreading and run into an issue because it’s turned off. I don’t know, but I’ve informed R&D and we’re going to gather information from the developers on this to see what we can come up with.

I’ll let you know (hopefully within a few days) the outcome. If you run across any new information that you feel is pertinent to us, feel free to post.

Thanks.

[Pacsoft]

Hi,

So does that mean R&D will release a new driver with this bug fixed ? That would be great, because we got several CDAQ chassis to make portable applications but it turns out that the laptops we are using are not capable of multithreading.

Regards

[Neal M]

Pacsoft,

I have used DAQmx on computers without hyperthreading (and ones with it turned off), and it worked fine.  I checked today by running an analog input example program on a cDAQ chassis/module with hyperthreading turned off and it worked quite well.  I know Mark has seen similar behavior to yours on one computer, but we are still not sure what is causing the problem.  R&D does know about this and will be investigating it as well.  I would suggest trying it on one of your deployment computers directly and see if you still have the behavior.

[Pacsoft]

Hi,

We have already tried the same application on different deployment computers and the same behavior is seen. As I wrote in the first post, when you make function calls from the main thread, everything works fine. The problem is when you make a function call from a secondary thread.

We have another completely different application that uses PXI, PXI Boards, TestStand and DAQmx. It is also multithreaded. That one crashes when Hyperthreading is disabled.

Regards

[Pacsoft]

Hi,

I found the following at NI's Discussion Forum. This person is also reporting similar issues with Hyperthreading:

http://forums.ni.com/ni/board/message?board.id=250&message.id=24104&requireLogin=False

Regards

[Neal M]

Pacsoft,

When you say that you only see this in secondary threads, are you refering to UI callbacks?  This does create another thread, but from your above post, these seem to be working for you.  Have you taken a look at the CmtScheduleThreadPool function?  Using this could eliminate using CVI UI callbacks as the source of the problem.  I will set up the system I had again and make sure that hyperthreading is disabled to see if I can reproduce the problem on a third computer. R&D has assured me that DAQmx can been used without hyperthreading.  My thought is that there is a chance this could be an issue with how CVI handles things.

I would like to narrow down causes as much as possible.  Could you give me a better idea of what machines you see this on (CPU, etc)?  Also, what were the results of using a simulated device?

[Pacsoft]

Hi,

Are you saying that UI callbacks are handled in a secondary thread ? I did not know that. I was assumign that the CVI Run Time was some sort of wrapper hidding the message pump of an application written using plain Win32. And also I though that UI callbacks were executed in the primary thread because if you perform a long task within a UI callback, the whole application freezes until the function returns. In Win32, function calls are always executed in the context of the primary thread, except you explicitly code it differently. What I was trying to explain is that if we made a DAQmx function call from a UI callback, the function returns quickly, just as expected.

I have new data. We tried using a simulated device and the problem is still there. I takes a long time for a DAQmx function call to return. The CPU in which we have seen the problem is Pentium M running at 1.4 Ghz with 768 MB of RAM.

Regards