Ben would like your opinion on hardware suggestions for demanding app.

[Ben]

I am going to develop a 16 channel sound and vibration monitor capable of 20KHz bandwidth in LV. I would like to maintain 16 live JTFA displays with logging.

I would like to be able to run this continuously but if have to throtle the run time, we can work with that.

I will be using a pair of 4472's in a PXI chassis supported via MXI-3.

Questions follow;

1) I am concidering pruchasing a dual proccessor 2.4 GHz tower with 1.5 Gb of memory.
a) Will I have to specifically bind different tasks to each proccesor to be able to take advantage of the dual proc?
b) If I do not specifically bind tasks, does the dual proccessor buy me anything in LV?

2) With 16 JTFA displays I can see a lot of
work in the screen updates. Should I concider a fancy graphics card?

3) Are there any complications with running a dual processor and MXI-3?

4) Are there tools that let me see how busy each CPU is?

Please feel free to offer any other suggestions that may help.

I thank your time.

Ben

[Jeremy Braden]

Wow, you ask good questions. Let me give you my two cents.

I assume that you are going to use Windows, and it is my understanding that Windows hides the dual processing from the user. I do not know of a way to direct a thread to a particular process. Because LabVIEW by default uses two threads--user interface and processes--you should see a performance increase because the work of the VI can be spread across processors. Because LabVIEW is not compiled for a specific video card, I think it would be unlikely to benfit from a fancy video card. I imagine you will see improvements but LabVIEW will not be able to take advantage of the advanced features of the card. There have been no reported issues with using MXI on a dual processor machine. MXI is just a
pci bus extension so the dual processors should not affect it. Finally I am told that there are tools to seeing the processor load but do not know of any to suggest.
You may consider posting again after the holidays when more people have returned from vacation.

[Ben]

Thanks for the reply Jeremy!

So far so good.

I think I will repost again as you suggested (there is wisdom in a multitude of counselors).

Ben

[preston_johnson]

Sounds like a very interesting application, Ben. I agree with the recent response regarding dual processors. Memory and Speed will certainly help with your app.

As Business Development Manager for machinery vibration applications, I am curious what your unit under test is? One JTFA tool NI offers is the order analysis toolset which tracks orders using the gabor transform. Perhaps this tool would be useful. I am interested in learning more of your requirements.

For the business of the CPUs, I typically use the Windows task manager meter. It gives some indication. You might also use the LabVIEW profile tools to see where your code is spending time. Do be sure to use double buffered background DAQ to insure best performance.

Finally, we
do have VIs that will synchronize multiple 4472s over RTSI and produce one waveform datatype wire with all 16 channels bundled in. Let me know if you would like to see these.

Sincerely,

Preston Johnson
Business Development Manager
preston.johnson@ni.com
512-683-5444

[Andrew Madry]

Ben
We did a high end job like yours this year. It was for multi-channel recording of electrophysiology data. We used a PXI chassis with 4 6070 cards and MXI-3. We chose a Dell dual Xeon 2GHz for the job. I had the same questions as you re the benfits of using a dual processor machine. Our application required saving data to disk at a minimum rate of 8MByte/sec. It also needed to do processing on this data and display it. There is a useful NI article on DevZone "Performance Benchmarks for Modular Dynamic Signal Acquisition Systems" which you may have seen.

Despite various specs around the write to disc speed was faster than we could reliably get with ATA hard disk drives and any speed processor. We looked at various hard disk options including SCSI, Raid and specialist devices like StreamStor from Boulder Instruments. In the end we chose Ultra160 SCSI drives (15000rpm). These easily met our write to disk speed performance requirements.

I liked the idea of the dual processors because I thought it would be good if we could assign the task of writing to disk to one processor. It was essential that data acquired was written to disk with nothing lost. I'd therefore want a big safety margin for this processor eg only load it at 50%. The real-time processing of the data for display on the screen could on the other hand could miss a beat now and then. I figured we could load the processor for this task up to close to maximum. If the processing of data can't keep up with acquisition then just miss processing some data and go on.

In the end the machine met our requirements without any fine tuning so we didn't look much further into optimising performance by having two processors. We used Windows 2000 OS. Looking at the performance meter provided in Windows 2000 you can see what each processor is doing. It seemed that most of the time the processors were equally loaded.

We searched around the web and the info LabVIEW for suggestions on use of dual processors but didn't come up with much. I saw one posting that suggested a way to allocate a program to one processor or the other. This is done via Windows so you would have to write 2 separate exes to do this. Maybe you could use communications protocol (TCP/IP or NI's datasocket) to communicate between the programs. Not sure what the overhead of this would be. As I said Windows and LabVIEW seemed to divide up the app to meet our needs without having to do this.

I plan to write a detailed app note on what we found regarding disk writing speeds early in the new year. I want to get a better handle on the use of dual processors and may get round to doing some more investigation on the machine we installed for our customer. Email me via our website at www.madry.com.au if this would be useful.

Regarding the graphics card we selected a video card from Dell that supported dual monitors. This worked really well with LabVIEW. It worked with no problems like one big monitor. In LabVIEW you can set the front panel screen size programatically depending on whether both or one monitor was present.

The MXI-3 with optical fibre worked with no problems.

regards
Andrew Madry

[Ben]

Thanks for the response Andrew!

This is great info.

As long as I write good code, this sounds do-able.

As I go along, I will update this question with what I figure out.

Ben

[Ben]

Hi Preston,

I will take you upon that example code that has been teested to acquire from multiple 4472's in a PXI chassis. Could you point me at a link?

The application will acquire sound and vibration information from a high speed pump. The exact data will depend on what the user connects the inputs up to. The app is supposed to be flexible. That's why I suggested a combination of JTFA plots with realtime FFT's.

Ben