Dual Core DAQmx Acquisition Glitch Problems on Athlon64

[Matt_W1]

The TSC problem affected a lot of stuff (would cause nasty jitter in certain games, which is where I first ran across it). And the updated drivers should correct the problem (and in single CPU mode it really should be a non factor). So I'm doubting the problem is related to the TSC.

I'm not sure what your requirements are for a motherboard, so I can't make a good recommendation. But ASUS makes boards with AMD and nVidia based chipset if you want to stick with them (My guess is that the chipset would have a bigger influence than the manufacturer as long as they're both good). I've had good luck with MSI and Gigabyte if you want a different brand. I had an incompatibility problem with a VIA chipset and a gigabyte NIC about 5 years ago, which is way I'm thinking it's the chipset.

Here's an idea perhaps the power management feature is varying the cpu speed and causing the bumps. You could run an intensive program like Prime95 (in stress test mode), and set it's priority to low in the task manager (so your cpu usage will stay at %100, but should affect your program). Or you could disable the cpu speed varying feature in the BIOS (I would tell you where it was if I could get the manuals off of ASUS's site). I think it's called Cool'n'Quiet, but I could be wrong.

Matt W

[Jordan N.]

Thanks.  I do have the Cool n Quiet disabled already.  I believe that is the default on these boards anyway so I don't feel uncomfortable about doing that at all.  I also did try something similar to your suggestion by downloading programs that are designed to hog the CPU time, some to throttle the CPU down while in Windows, and some to prevent any power management throttling.  Unfortunately, no luck on any of these.

WinThrottle
CPUKill
CPU Grabber
Speed Switch XP

We also have a old DOS app that requires a high idle sensitivity which really slows the system down.  I really did not see any noticable difference when the app was running by itself unhindered, when it ran with a program that hogged the CPU, or a program that kept the CPU at PM disabled (max speed).

One would think that if lowering the CPU multiplier in the Bios was able to stop the problem then the program designed to put the CPU into a power managed state and lower the clock speed would have produced similar results, but it did not.

I think I am going to try to see if this happens on Windows 2000 next.  I don't want that to be the solution just like I don't want keeping the CPU clock low to be the solution.  We can't work our way backwards through technology, but it might be another piece to the puzzle of what is going on.

[Matt_W1]

My guess is still that it's an incompatibility between the chipset and the NI card (have you tried a different card model). Since it sounds like you've changed everything else. Certain sound card ands motherboard combinations would lead to  popping and crackling sounds (and sounds cards have some strong similarities with DAQ cards, at least at the analog level). I think the problem was related to the PCI bus being saturated. Does the sampling rate affect the problem or copying files around the hard drive and/or using the network card while sampling affect it? Have you tried updating the motherboard firmware (and/or drivers)?

Matt W

Message Edited by Matt W on 09-13-2007 07:11 PM

[Jordan N.]

We have used the firmware as delivered and also update to the latest.  I have also tried disabling the Sound, Com Ports, LPT ports, and USB ports in the BIOS.  I have also moved the 6251 into all 5 available PCI slots in the computer with these components disabled.  None of these has helped.  I cannot disable the NIC because the app we developed requires getting the test parameters from the database, but it closes the DB connection right after getting the params then no other NIC activity as far as I can tell.

Also tried running in VGA mode as well (not Safe Mode because drivers for the 6251 will not load either)

[Matt_W1]

I was asking if increasing network and/or harddrive load made the problem worse (since this would strongly imply a problem with the bus). You could just copy some files over the network while running the program.

Matt W

[billings11]

Ultimately NI wants developers to use PXI chassis with NI's proprietary PXI industrial PC and all PXI cards.  That's why they will sit on a problem with PCI for years and never tell anyone or do anything about it.  I don't think their margin is very good at all on PCI hardware.  They have a lot of competition, and it takes a lot of money to support.  PXI is easier because they can test their products with only their own PXI plug-in PC's, plust all the PXI stuff is much more expensive so I'm guessing NI makes much more money off it.  I think at the executive level NI allocates only so much money towards PCI support, and they probably allocate an amount of money proportional to the profits off PCI DAQ products.

We are really going against the concepts that NI's sales team tries to target us toward.  We don't use PXI even though we have a bunch of industrial manufacturing applications.  We don't use teststand even though we have high mix products and very customizable test sequences.   We've saved huge money by not using PXI and writing our own sequencing engine in labview instead of paying a per-station licensing fee for teststand.  This is the tradeoff I guess.

At the very least though, NI should provide its customers a list of known compatibility issues for PCI DAQ products.

[Jordan N.]

Not sure if this totally eliminates a bus issue, but here are the results from the file copy test over the network - No difference in any results.

1. When I lower the CPU multiplier down just far enough to prevent the issue (From 2100 to 1900) and I copy two 500 MB files off the network down to the hard drive I do not see the issue just like before.  I would think if it were a bus issue the huge data transfer over the NIC and HD would rattle something, but it did not.
   
2. When setting the computer to its defaults by not dumbing down anything and trying the same file copy test I did not see anything that appeared to make it any worse that it already was.
   
3. Final test was to leave the CPU at full speed, but add /onecpu to the Boot.ini file.  This usually improves the spiking a bit.  After doing this and copying the two 500 MB files I did not see any noticable change either.