Hyperthreading and error -200016

[JSA]

For quite some time, we have noticed that our software gets flaky when running on a Hyperthreaded machine.  Not having the time to troubleshoot until recently, we've always just turned off Hyperthreading and gotten on with life.  However this is becoming more of a nuisance.

The software continuously outputs and reads in data at 10KHz using the PCI-6036E.  The behavior manifests itself when using both Traditonal NI-DAQ as well as NI-DAQmx (it was one of the issues I had hoped would go away after switching to mx).  I finally got an HT capable machine to install my tools on (Visual C++ on a P4 2.8GHz) and I got a reliable way to reproduce the issue: wiggle the mouse!  If I don't touch the mouse when starting the process, it will run indefinitely.  As soon as I give the mouse a good wiggle, BOOM!  -200019.  This issue completely disappears if I disable Hyperthreading.

I figured there was something I was doing wrong in my code (which is fairly heavily threaded, and thus prone to errors on a "multiprocessor like" system).  Well, imagine my surprise when today I fired up the test panel in NI-MAX, started an output task at 10KHz (I don't even need to start an input acquisition), wiggle the mouse and BOOM!  -200019.  Well, this made me feel better as a programmer but not as a maker of reliable software.  The problem goes away if I output at 5KHz, but that is way too low for our app.  We could get away with 8KHz, but it still happens then (though it's harder to reproduce).  I have tried manually manipulating the buffers in endless combinations, but it never does any good.

Is there any way I can get this to run on a HyperThreaded system?  I really hate having to tell our customers to turn off the HT in their system, and I don't think I should have to.

Thanks for any guidance,
John

P.S. This behavior is identical on HP computers, Dells and homebrew systems.  So it is not PC specific, the common denominator is always HT.

[reddog]

The PCI-6036 only has one DMA channel and no AO FIFO.  By default, the driver will give preference of the DMA channel to the analog input task.  That means the AO task must transfer data via interrupts, and since there is no AO FIFO, your system must service 10,000 interrupts per second and must service each interrupt in 100 microseconds or less or you'll get a -200016 FIFO underflow error.  My guess is that when hyperthreading is enabled, the system (or driver or both) incur some additional overhead to switch context and service and handle the interrupt in a thead safe manner.  This additional overhead may be enough to tip the balance on your AO task when hyperthreading is enabled.  My suggestion would be to try to switch your AI task to using interrupts and your AO task to using DMA.  I don't know if this will be enough to eliminate the underflow error completely, but it's probably your best bet short of disabling hyperthreading.  Control of these properties can be found in the DAQmx Channel Property Node and navigating the following menus:

Analog Input->General Properties->Advanced->Data Transfer and Memory->Data Transfer Mechanism

Analog Output->General Properties->Advanced->Data Transfer and Memory->Data Transfer Mechanism

[JSA]

Thanks, that seems to have worked... it's probably something I should have been doing all along but I didn't even know I *could* choose DMA or Interrupts on my own.  Figured the card would take care of that.  Now I have to generalize my library so I can automagically choose the most efficient method based on what card is being used (we're slowly migrating towards M series cards, which I guess would not have had this problem in the first place).

[AlanArmstead]

Great post reddog!  I just wanted to mention that M Series DAQ devices have 6 DMA channels, and all that have analog output channels do have an onboard output FIFO (Size = 8191 Samples, shared among all channels).  Just FYI.

-Alan A.