Does CVI support the new, dual-core processors?

[GUI Guy]

Our LabWindows/CVI GUI hangs when run on a new, dual-core processor PC. We used CVI 7.1 to build it and were wondering if the new versions (8.0, 8.0.1) have support.

[menchar]

Good topic - NI's usual answer is to try running the 8.0 runtime engine.

We're having trouble with a CVI 7.1.1 app running on a dual micro AMD motherboard (four cores total).

We think it's more likely the Conduant framegrabber we're using that has the problem.  The DLL they supply is creating a bunch of threads and I think they may have a race condition when running on a truly concurrent system.

Prior to this, we had trouble on a dual micro (four core with hyperthreading) system and the com ports.

We now use the NI 843x serial board that comes with the NI "plug in" (kernel mode I think this means) driver that NI asserts specifically to be hyperthread compatable.

There's a class of threading errors that only show under true concurrency.  The errors could be in your app, or in a driver.

[Matt M.]

Hi GUI Guy,

Menchar is correct - I would suggest that you try running your application with our 8.0 CVI engine.

However, to give you a more specific answer, I am going to need some of your system and application specifications. CVI has support for multithreading and multiprocessor systems (links provided below) leading me to believe that there might be a problem in your application.

I would start by stepping through the program and finding exactly where it hangs. If you can drill down to the where the problem occurs, we can more accurately analyze your problem.

A really thorough document is Multithreading in LabWindows/CVI. 

Matt Mueller
National Instruments

Message Edited by Matt Mueller on 08-28-2006 09:45 AM

[menchar]

Simply saying to run the "8.0 runtime engine" without being specific about a problem or vulnerability that may have existed that was repaired in the newer runtime sounds like a copout.

Is there a known problem / vulnerability in the 7.1 runtime engine in re multi-processing?

Menchar

[GUI Guy]

Matt,

I believe the hangup is in the RS232 com routines, but I don't have a dual-core system to debug on yet, though that's coming. The computer we have that hangs is a Dell 6400 laptop and it has a Trendnet TU-S9 USB to serial port adapter (shows up as com 4).

When the computer is locked to processor core 0, the problem goes away.

Alex (GUI Guy) Specker

Precision Filters Inc.

[Matt M.]

Menchar,

I am unaware of any problems or vulnerabilities in the CVI runtime engine for multiprocessing. I would suggest trying to use the latest version of the runtime engine simply because it is our most complete version of the runtime engine. CVI 8.0 also offers direct connectivity with third-party optimizing compilers, so you can run applications faster.

As far as handling threads, definitely check out the links I posted before (specifically, Multithreading in LabWindows/CVI) for more information.

Matt Mueller
National Instruments

Message Edited by Matt Mueller on 08-28-2006 10:54 AM

[menchar]

Thanks for clarifying.



Menchar

Message Edited by menchar on 08-28-2006 09:38 AM

[Matt M.]

Alex,

Are you using CVI's built-in RS232 com routines? NI's RS232 library is designed to be thread-safe and protect against simultaneous access so if you are trying to access it, so you could be experiencing delays there if multiple threads are trying to access the serial port.

I'm not sure what you mean by saying you lock your computer to processor core 0 when you only have one processor. I assume you are keeping your program multithreaded?

Are you getting you getting timeouts when you access your serial ports? If you, you could try decreasing your timeout using the SetComTime function. This should help increase the speed of timeouts

Also, you should call ProcessSystemEvents() every time you access RS232 over USB. If this doesn't help, try adjusting the settings of your USB driver (e.g. Device Manager->USB Serial Port Properties->Port Settings->Advanced). Your driver might be able to be configured to work better with RS232 applications. Uncheck, "Use FIFO Buffer" and try running your application (with ProcessSystemEvents()) again.

Matt Mueller
National Instruments

[menchar]

Matt -

He's setting the thread affinity for the process most likely, using the task manager.

Com port problems on multi-core systems are a known problem.  We had to do the same thing on a CVI app using the NI rs-232 library, which in turn was using the native Windows serial driver.  We used the 843x card and NI 1.8 serial driver and no more serial problems on a multi-core system (we think).

Setting thread affinity using task manager is on a process basis only.  If you're invoking other code in another process (with RPS, or by using a DLL that's created its own threads and was registered initially by some other process) I would think you're still potentially going to have code in your process running on multiple cores.  All thread affinity does is ensure that Windows only schedules the main thread and any threads created by the process (which inherit the thread affinity) on a single core.

You can set the NUM PROC switch in boot.ini to 1 using msconfig.  This forces all code in the system to run on a single core.  Pseudo-concurrency Vs. true concurrency. 

You can't prevent Windows from running multi-threaded - it's just an issue of whether or not it's more concurrent hardware-wise.  Hyperthreading is not as fully hardware concurrent as is an SMP design.

You can turn hyperthreading off in the BIOS.  This doesn't work for a multi-core AMD micro apparently.

Hyperthreading shows as multi-cores to WinXP the same way as multi-processors but it's not really the same.

See Windows Internals, Microsoft Press ISBN 0-7356-1917-4

[GUI Guy]

Menchar,

Yes, you hit the nail on the head. We have to set affinity to single core (proc 0) on a dual-core system and then we don't get the errors. Regular, single-core systems are fine; we've sold this app for many years now without com problems. Also, this app is single-threaded; it just runs a GUI that is connected via a com port/GPIB/TCP to our signal processing systems and test equipment.

Alex