Hardware for high performance

[therealkilkenny]

Hi all,

Tried to track down the answers to my question but couldn't turn up much.

I have developed a LV application (LV 8.5) for controlling some PCI cards (via dll's) for use in ultrasound. There are 3 PCI cards in the system - High voltage pulser (Spike pulses consisting of voltage up to 400V, pulse width as low as 100ns and pulse repetition rate of up to 100 kHz), Multiplexer/reciever (8 channels splitting the (up to) 100,000 pulses out into 8 channels (thus up to 12,500 pulses per second per channel) and receiving the pulses as they come back from the sensor and amplifing them), and a digitiser taking the (up to 100,000) recieved pulses and doing hardware measurements on the pulses and/or digitising them at 100MHz and 12Bits (each pulse thus consists of at least 1000 data points, each with a minimum value of -2047 and maximum of 2048). Additionally the system takes in up to 6 encoder inputs to give a measurement of angluar position on up to 6 encoders. I need to do calculations on each hardware measurement and frequency analysis on each

Needless to say all this is streching the program and hardware to the limit (up to 100,000 pulses with 1000 data points per pulse - 100,000,000 data points per second). I'm currently running slower than this because the PCI cards are in a system that doesn't have a good spec and just saving the data for later post processing. I also want to view what is happening on the screen so that i can monitor what is happening on all 8 channels.

The questions that i have are as follows:

- What sort of Processor should i look for. I understand that LV makes use of dual core processors. Is that correct? Should i also look for a fast processor?
- How much RAM should i have? I guess that at least 2GB? Can LV handle 4GB?
- What sort of graphics card should i have? Will a super-duper graphics card with 512MB of RAM enable the LV program to run faster?
- What can i do interms of speeding up read/write to disk. The data is all currently being saved as Binary, but would a RAID array speed things up?

Any help would be great. Thanks.

Phil

[Pnt]

Labview is a progamming language. The faster the PC is, the faster it will run...

The RAM that Labview can handle is much bigger, no need to worry.

Although it is good to have a fast PC, i think a good programming style is much more importand.

[KostasB]

Hi,

With regard to your questions:

1) LabVIEW does make use of multicore processors however the Windows OS will decide which thread will run in which core. With LabVIEW Real-time, you can explicitly assign

specific operations to specific cores. More information on multicore can be found on http://www.ni.com/multicore/

You would need a fast processor if you have intensive signal processing algorithms or large amounts of data.

2) LabVIEW can handle more than 4Gb of RAM- however 32-bit processors can not. You should consider using 64-bit processors if your application requires more RAM.

The following article explains that in detail.

http://zone.ni.com/devzone/cda/tut/p/id/5709

3) I don't see how the graphic card would affect performance as the user interface is probably not going to be demanding. The following link describes gives some tips.

http://forums.ni.com/ni/board/message?board.id=170&message.id=203814&requireLogin=False

4) Speed write/read to disk. The speed of the hard disk is important as of course good programming techniques. Saving to disk in the same loop as the acquisition is an example

of a bad programming technique.

My concern would probably be the PCI bandwidth which is 132Mbyte/sec across all of your PCI cards.  And also how you actually syncronise those cards ( using RTSI cable?)

Kind regards,

KostasB

National Instruments Applications Engineering

[Matt_W1]

In LabVIEW 8.5 you can assign specific tasks to specific cores with a timed loop (in general it's better to have the os manage where the threads are run).

LabVIEW does not handle more than 4GB of memory since it still a 32 bit program (even on a 64 bit os, hopefully a 64 bit version of labview will come out). The limit was 2GB until 8.5, which can take advantage of the /3GB flag, so the the limit should be 3GB on 32 bit windows with the /3GB flag enabled in the boot.ini (note this greatly decreases the resources windows has access to, which may lead to problems depending on you're computer and what it's doing). In theory under 64bit windows LV could use all 4GB of 32 bit address space, but I've never tested that.

The video card shouldn't make much of a difference speed wise (since you're not doing heavy 3d rendering). If you end up pushing the ram limit in a 32 bit os, you'll want a video card with a smaller amount of ram, since the video card memory uses up some of the 4GB address space. For instance if you went crazy and got two cards with 1GB of ram on each then there's no way you could ever use more than 2 GB of ram (since 2 of the 4 GB of address space is taken up by card memory). This is not a problem on a 64 bit os since the address space is large enough that the cards and ram don't have to overlap (technically some of the older motherboards would still overlap the ram and video memory space).

 If you need to stream the data at more more than ~35 MB/s You could use a raid 0 (being the fastest raid for streaming data, note it has a higher chance of failure since any drive dieing will destroy all the data on the array, so be sure to have a backup system), a single raptor drive should handle data up 50 MB/s (the inner tracks are about 90MB/s). One of the newer solid states can handle 110 MB/s.

I would agree on the concerns about PCI bandwidth, if you're streaming data to disk, you definitely want the hard drive controller on a separate bus (this is true of most built in hard drive controllers on current motherboards), this is also true of a PCI-Express based controller. Some of the high end server motherboards have separate PCI buses, which could help. The ideal solution would be having PCI-Express versions of the card (since PCI-E doesn't share bandwidth).

Another idea (which may not be viable), would be to replace some or all of the cards with something like a R Series board and having the fpga do the heavy calculations (I've been wanting to play of those out to see what it can do, so I may be over estimating their capacity).

Matt W

[therealkilkenny]

Hi Guys,

Thanks for the replies! Very helpful.

The only PCI card that is sending data into the computer over the PCI bus is the Digitiser card. The other cards are only controlled during set up to set things like pulse repetition rate, voltage, pulse width etc. The cards are all hardware controlled so it hasn't been to much of a problem to write the driver and get the software running. It's now a matter of optimising and stretching it to it's limit.

The driver still has some functionality to implement and for the moment i'm limited to grabbing one pulse at a time (1-d array of 1000pts) via a call to the dll. I then write that to file using write to binary file. I then make the next call. I've experimented just grabbing the data with and without saving and there is not much of a noticable drop in the capture rate (i'm making about 250 calls to the capture data dll per second and about 2000 calls to another dll per second to extract the data - 8 channels so about 250 captured waveforms per channel per second).

Do you think i should send the data out of the loop before saving it?

Thanks.