Dell GX-280 (3 GHz Hyperthreaded)

[hirschmann]

Dear Sirs or Madams,

after upgrading from a slow Dell PC to a new Dell GX-280 (~ 3 GHz, hyperthreaded),
our MXI-2/VXI card has stopped functioning properly. The correctness of read results
from VME now depends on the readout frequency. Reducing the readout frequency by
inserting a 1 ms wait time period in our LabView program serves as a workaround,
yet renders VME access almost unusable to us.
We have seen on your published lists that there are other issues with that cards
related to state-of-the-art PCs faster than 2.5 GHz and hyperthreading.
We need a fast workaround to

a) Keep VME readout speed
b) Get correct Read/Write Results when operating on VME

Kind regards
Thomas Hirschmann
Master of Physics, PhD

[ScotSalmon]

Can you elaborate on the correctness problem? We have seen performance problems and, in some cases, errors in certain combinations of PC chipset, controller hardware, and software settings, but we have not seen any correctness problems.

-Scot

[hirschmann]

Hello Mr Salmon,

we are reading out VME data using a LabView application and the VISA library. On fast subsequent
readouts, only the first data is stable. All following data is (nearly) random. Using NI spy with active
capturing we observe that the interference of this debug tool creates a delay which seems to be large
enough to inhibit the malfunctioning. Inserting a millisecond delay in between subsequent readout obviously
has the same beneficial effect.

This is the Ultra DMA driver version of the Optiplex GX-280 we have been using

Title : Chip Set:Intel Chipset Software Installation Utility Driver
Version : A09
OEM Name : Intel
OEM Ver : 6.0.1.1002
Computers : Dimension - 4700, XPS Gen 3, 8400, XPS Gen 4;
OptiPlex - SX280, GX280;
Precision - 370, 670, 470
Oses : Windows 2000 Professional,Windows XP Home Edition,Windows XP Professional
Languages : Brazilian Portuguese,Chinese-S,Chinese-T,English,French,German,Japanese,Korean,Spanish
Created : Mon Nov 8 18:14:53 CST 2004

The chipset is an Intel 915G/P/GV, with an Intel 82801 PCI bridge.

The VXI driver has the version number 3.3.1.

Kind regards
Thomas

Attached is the output of ni spy.

[ScotSalmon]

Do you have access to a VME logic analzyer that you could use to compare the data present on VME to the data received?

I looked at the Spy capture. Are all of the reads in your application done using viIn, or are there viPeek or viMove[In] operations as well, that are perhaps not shown in the Spy capture? Do you have your system configured to share host RAM for dual-ported access with viMemAlloc?

Also, feel free to attach the original Spy capture file (.spy) and not just the .txt file. The .spy file contains more details that may be useful in debugging.

Just to clarify and hopefully ease your concerns about your setup, we do test and use the MXI-2 system on many modern computers including hyperthreaded, multi-GHz machines like yours. We have never seen a problem where the MXI-2 starts returning incorrect data. The known issue we have had with certain recent chipsets affects DMA on our older drivers (although the problem can occur on newer drivers), but the result is not bogus data. Instead, the result is that a viMove or Fast Data Channel viRead/Write operation (never viIn) might be unusually slow or fail with a VI_ERROR_IO (or possibly other errors in older drivers). There are additional details in various knowledgebases such as document 2MIFSIPG on ni.com.

-Scot

[hirschmann]

Hello,

unfortunately we are not able to apply a logic analyzer at the moment.
The read access in our LabView application is as follows:
o viIn() is called repeatedly in a loop, no other vi calls placed inside this loop
o No viPeek or viMove() calls are used.

We are using default settings according to the "Getting started" manual (no memory shared, see table A-5, line 1).
Please note that we do not receive any bus errors when we get the bogus data.

Regards
Thomas

Please check the *.spy file in the attachement.

[ScotSalmon]

Thomas-

Thanks. With the simple setup you've described, there are relatively few things that could be going wrong with the software. Have you tried a different MXI-2 controller?

We can continue investigating along a few different paths, but I think it would be helpful to get in more direct contact with you. Please submit an email request at ni.com/ask so we can get into further details. I think my next step might be to try using viPeek instead of viIn (you'll need to use viMapAddress first, if you're not already familiar with how viPeek works) because viPeek is extremely simple from the software side. If that doesn't change anything (or even if it does) we can simplify the software further by writing a C-based version of the test program's read loop. Let's have you get in touch with us by email to discuss these and other diagnostic options.

Thanks again.

-Scot

[monster]

Same problem,turning off hyperthreading resolved everything!!!!Hope this works for you also.