AnsweredAssumed Answered

vrf Recursion

Question asked by VRFuser on Sep 20, 2007
If I understood your description, the download time is a significant limiting factor.  Can you speed things up by using two separate USB buses?  Maybe add a PCMCIA/USB card in the laptop to talk to the second laser or a PCI/USB card if you change to a desktop PC.  That could allow two VEE programs to talk to their respective lasers at the full USB bus speed rather than splitting up the bandwidth of one USB bus.  If you are bandwidth limited by the USB bus, it won't matter much if you are talking to the instrument from VEE, LV, C, or Assembly language.
 
We've been using VEE on multiprocessor machines since sometime in 2001 with great success.  We use Windows 2000.  (Note to Agilent: please don't drop Windows 2000 support in future releases.  We don't need the additional bloat of XP or Vista and don't want to be forced into a needless upgrade)  As others have said, a single VEE program will essentially only use one processor/core.  It will show a maximum of 50% CPU utilization in task manager on a dual processor/dual core machine.  In our software design, we use multiple VEE programs to take advantage of the multiprocessor environment.  For example, on our data acquisition machines we have one big complicated VEE program that acts as the primary user interface and one small simple rugged VEE program that handles monitoring the FIFO level, downloading the FIFO and creating data files.  I've experimented with assigning processor affinity for each VEE program, but don't really see any benefit.  You can bump up the process priority and get some performance gain, but you have to be careful not to generate other problems.
 
If you can upgrade to a dual core machine and use two USB busses with two VEE programs, it seems like you should be able to run each laser at roughly the same speed as you can run one with your current setup.  If processing the downloaded data is time consuming, you might review your VEE code for possible optimization or you could write some C code to do that piece and call it from VEE.
 
Corey
 


  _____  

From: S Wood [mailto:sfwood@harbornet.com]
Sent: Wednesday, September 19, 2007 6:15 PM
To: VRF
Subject: Fw: [vrf] Multicore processors


Thanks John, the last note cleared up a lot of confusion!
 
I have the laser process running on VEE 6, with two laser heads feeding one controller, and Vee processing and storing the data with a fast single core laptop.  The machining process is being upgraded to be nearly three times as fast, and the owner would like to have the laser system on the new machine.  The amount of time required to download and process the data already limits the number of grid points that can be taken since the laser controller is not dynamically buffered and VEE has to download all data before restarting each acquisition and then processing the download.  As I see it, I have a choice of trying to find different lasers, run two computers and controllers (one for each laser head), or make something like a fast multicore processor work.
 
When I saw the LV item on using multicore processors, I was hoping that I could use a dual core computer and VEE 8 to do identical parallel processing on the data from the two lasers, and two controllers would allow me to stagger the USB reads so that the acquisition null time would be split in half.  Vee is the only process running on the computer, and once started, the system is not touched until the run is finished, so there should be a minimum of windows overhead being split between the cores.
 
Anyway, I appreciate everyone's input - you have given me enough information to start educating myself about all of the choices and the windows options available through VEE and dot.net.
 
Thanks a lot everyone,
 
Steve
----- Original Message -----
From: HYPERLINK "mailto:john_dumais2@agilent.com"DUMAIS,JOHN (A-Sonoma,ex1)
To: HYPERLINK "mailto:vrf@agilent.com"VRF
Sent: Wednesday, September 19, 2007 2:48 PM
Subject: RE: [vrf] Multicore processors


Maybe it would help to better understand what you’re hoping to accomplish if you would explain a little more about what you’re wanting to do.  From what I think I understand, you have 2 devices, both on the same USB hub, from which you wish to get some data.  You want to get data from one without corrupting the data coming from the other.  Is that about right?

 

Assuming that it is, here are a couple things that may help to understand what the best approach would be…  USB is a round-robin kind of bus.  Each device on a given hub is assigned an ID and gets some amount of time to communicate on the bus, independent from everything else on the bus.  The OS keeps track of the individual device a piece of data came from/is going to.  The OS also keeps track of which thread created the operation that resulted in talking to a USB device.  So, if you have two processes, each of which talks to a different USB device, the OS will take care of getting the intended data back and forth between the originating thread and the target device, even though the USB devices are on the same hub.  That being the case, having two Vee processes (or any other kind of process) running at the same time talking to the 2 separate devices will not cause data corruption.

 

The 2nd thought is maximizing throughput.  If you assign each Vee process to run on a particular core, you may gain more parallelism and faster throughput.  You want to be careful about how you assign the process affinity mask, however.  The latest OS’s (XP & Vista) understand multi-core machines pretty well, and the thread schedulers do a pretty good job of balancing which core to assign threads to based on the amount of resources a thread is consuming.  So, if you assign processes to a given core, without knowing what else is going on in that core, that could result in slowing things down.

 

Make sense?

 

From: S Wood [mailto:sfwood@harbornet.com]
Sent: Wednesday, September 19, 2007 2:36 PM
To: PDL-LISTS,VRF (A-Lists,unix1)
Subject: [vrf] Multicore processors

 

This is a recap of my understanding concerning the multicore replies, please let me know if I am understanding correctly.

 

I have two independent USB laser controllers with on-board memory, and there is no requirement for the data from the two lasers to be simultaneous.

 

If I bring myself up to speed on .net and API use so that I know what I am asking for, I can have a VB, or C programmer provide me with dlls that can call the individual laser dlls (vendor USB) for a data dump, and then use individual processors for data storage and some processing outside of Vee. 

 

My only VEE timing concern would be that I allow enough time for the initial USB download prior to asking for the second due to sharing the USB.

 

In between reads, I can use VEE for data display, etc. until I am ready for another read - allowing the OS to time share this activity as it wishes. 

 

I realize that this is a very broad overview, but I am only hoping for some idea of feasibility.  From what I have read about using the multicore processors, major gains in throughput are only realized when the programming is explicitly set up for parallel operations on separate cores.

 

Thanks for all your replies,

 

Steve

 

 

 

 

 

 

 

 

 


---
You are currently subscribed to vrf as: john_dumais2@agilent.com
To subscribe please send an email to: "vrf-request@lists.it.agilent.com" with the word subscribe in the message body.
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@agilent.com".
If you need help with the mailing list send a message to
"owner-vrf@it.lists.it.agilent.com".
Search the "unofficial vrf archive" at "http://www.vrfarchive.com/vrf_archive".
Search the Agilent vrf archive at "http://vee.engineering.agilent.com".


---
You are currently subscribed to vrf as: sfwood@harbornet.com
To subscribe please send an email to: "vrf-request@lists.it.agilent.com" with the word subscribe in the message body.
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@agilent.com".
If you need help with the mailing list send a message to
"owner-vrf@it.lists.it.agilent.com".
Search the "unofficial vrf archive" at "http://www.vrfarchive.com/vrf_archive".
Search the Agilent vrf archive at "http://vee.engineering.agilent.com".
---
You are currently subscribed to vrf as: Corey.Wills@bnsf.com
To subscribe please send an email to: "vrf-request@lists.it.agilent.com" with the word subscribe in the message body.
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@agilent.com".
If you need help with the mailing list send a message to
"owner-vrf@it.lists.it.agilent.com".
Search the "unofficial vrf archive" at "http://www.vrfarchive.com/vrf_archive".
Search the Agilent vrf archive at "http://vee.engineering.agilent.com".


---
You are currently subscribed to vrf as: ming_meng@agilent.com
To subscribe please send an email to: "vrf-request@lists.it.agilent.com" with the word subscribe in the message body.
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@agilent.com".
If you need help with the mailing list send a message to
"owner-vrf@it.lists.it.agilent.com".
Search the "unofficial vrf archive" at "http://www.vrfarchive.com/vrf_archive".
Search the Agilent vrf archive at "http://vee.engineering.agilent.com".  

Outcomes