AnsweredAssumed Answered

vrf Multicore processors

Question asked by VRFuser on Sep 24, 2007

Like • Show 0 Likes0
Comment • 9

Dear VEE usrs,

Just prior to seeing the recent thread on multicore processors and VEE, I posting a link to my blog called "Is there really a multicore crisis?
It links to an article by Jim Kring called "LabView and the Mutlicore Crisis." Kring argues that software must be completely rewritten to take advantage of multicore processors. Here's the link.

http://www.tmworld.com/blog/1430000143/post/1320014732.html

Martin Rowe
Senior Technical Editor
Test & Measurement World
781-734-8419
m.rowe@tmworld.com
Listen to my songs "The Measurement Blues,"
"The lab in the corner," and "Check designs for EMI early" at www.tmworld.com/blues

---
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".

No one else has this question

Outcomes

9 Replies

VRFuser Sep 19, 2007 1:35 PM
Mark Correct
Correct Answer
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: 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".
Like • Show 0 Likes0
Actions
VRFuser Sep 19, 2007 2:49 PM
Mark Correct
Correct Answer
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: 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".
Like • Show 0 Likes0
Actions
VRFuser Sep 20, 2007 7:33 AM
Mark Correct
Correct Answer
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".
Like • Show 0 Likes0
Actions
VRFuser Sep 20, 2007 9:07 AM
Mark Correct
Correct Answer
Corey, thanks for the information - you can't beat hands on experience.

I am considering using two USB cards and two identical VEE programs, each calling a "C" routine to process the data from one laser as you suggested. A couple of quick questions:

1) If I have a separate "C" routine to reduce the data from each laser, would that make it worthwhile to allow the individual "C" routines to set a higher affinity for individual processors during the data reduction, or do you still feel that XP would do a better job of prioritizing the core usage?

2) I use the company intranet for post test data transfer to a server, but the company intranet has a habit of randomly grabbing any online computer for security downloads, so I have to disconnect the data acquisition machines during testing. Does dot.net have functions that allow VEE to programmatically disconnect and reconnect to a LAN?

Thanks,

Steve

---
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".
Like • Show 0 Likes0
Actions
VRFuser Sep 20, 2007 9:25 AM
Mark Correct
Correct Answer
"S Wood" <sfwood@harbornet.com> wrote:
> Corey, thanks for the information - you can't beat hands on experience.
>
> I am considering using two USB cards and two identical VEE programs, each
> calling a "C" routine to process the data from one laser as you suggested.
> A couple of quick questions:
>
> 1) If I have a separate "C" routine to reduce the data from each
> laser, would that make it worthwhile to allow the individual "C"
> routines to set a higher affinity for individual processors during the
> data reduction, or do you still feel that XP would do a better job of prioritizing the core usage?
>
> 2) I use the company intranet for post test data transfer to a server,
> but the company intranet has a habit of randomly grabbing any online
> computer for security downloads, so I have to disconnect the data
> acquisition machines during testing. Does dot.net have functions that
> allow VEE to programmatically disconnect and reconnect to a LAN?

probably-- but you certainly don't need dotNET to do things that work from a command line. One way to do this would be to pause the appropriate service using an "execute program". The "net"
command can probably do what you need. You would of course need administrator privileges to do this.

If you are on a secure system and can't hard-code administrator access, you could look at a hardware solution:
use any cheap DIO to power down a network switch disconnecting your machine from the network.

Don't know about others, but I for one would be very reluctant to second-guess the OS's processor assignments.

Stan

--------------------------------------------------------------------------
Stan Bischof Agilent Technologies 707-577-3994 stan_bischof@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".
Like • Show 0 Likes0
Actions
VRFuser Sep 20, 2007 9:34 AM
Mark Correct
Correct Answer
I would try it first without setting processor affinity or process priority. No sense messing with that stuff unless you really, really need it.

Regarding question 2, I really don't know. I'm certainly no .NET expert. I'd bet you can do it through a windows API call.

Corey

_____

From: S Wood [mailto:sfwood@harbornet.com]
Sent: Thursday, September 20, 2007 11:07 AM
To: VRF
Subject: [vrf] Multicore processors

Corey, thanks for the information - you can't beat hands on experience.

I am considering using two USB cards and two identical VEE programs, each calling a "C" routine to process the data from one laser as you suggested. A couple of quick questions:

1) If I have a separate "C" routine to reduce the data from each laser, would that make it worthwhile to allow the individual "C" routines to set a higher affinity for individual processors during the data reduction, or do you still feel that XP would do a better job of prioritizing the core usage?

2) I use the company intranet for post test data transfer to a server, but the company intranet has a habit of randomly grabbing any online computer for security downloads, so I have to disconnect the data acquisition machines during testing. Does dot.net have functions that allow VEE to programmatically disconnect and reconnect to a LAN?

Thanks,

Steve

---
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".
Like • Show 0 Likes0
Actions
VRFuser Sep 20, 2007 9:48 AM
Mark Correct
Correct Answer
Thanks to all,

I will let you know how it works out and what problems I run into. When I get the system running with the OS prioritizing everything, then I will try assigning processors and let everyone know how that works out also.

Thanks,

Steve
----- Original Message -----
From: HYPERLINK "mailto:Corey.Wills@bnsf.com"Wills, Corey D
To: HYPERLINK "mailto:vrf@agilent.com"VRF
Sent: Thursday, September 20, 2007 9:33 AM
Subject: RE: [vrf] Multicore processors

I would try it first without setting processor affinity or process priority. No sense messing with that stuff unless you really, really need it.

Regarding question 2, I really don't know. I'm certainly no .NET expert. I'd bet you can do it through a windows API call.

Corey

_____

From: S Wood [mailto:sfwood@harbornet.com]
Sent: Thursday, September 20, 2007 11:07 AM
To: VRF
Subject: [vrf] Multicore processors

Corey, thanks for the information - you can't beat hands on experience.

I am considering using two USB cards and two identical VEE programs, each calling a "C" routine to process the data from one laser as you suggested. A couple of quick questions:

1) If I have a separate "C" routine to reduce the data from each laser, would that make it worthwhile to allow the individual "C" routines to set a higher affinity for individual processors during the data reduction, or do you still feel that XP would do a better job of prioritizing the core usage?

2) I use the company intranet for post test data transfer to a server, but the company intranet has a habit of randomly grabbing any online computer for security downloads, so I have to disconnect the data acquisition machines during testing. Does dot.net have functions that allow VEE to programmatically disconnect and reconnect to a LAN?

Thanks,

Steve

---
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: 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: 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".
Like • Show 0 Likes0
Actions
VRFuser Sep 21, 2007 6:21 AM
Mark Correct
Correct Answer
Use the right tool for the right job.

If you wish to take advantage of a multi-core processor like a duo or quad and wish to continue to use VEE try the following:

Build your primary operating code within VEE. Structure is important.
Build your multi-core routines within .Net.
Drop your .Net into VEE as a stand alone module that updates either a memory location visible to VEE or a disk file.

Since the .NET code would be standalone and free running within VEE a file would be easier, but good attention to structure will keep your mod callable. I like a single call. You might want your .Net to have a protocol for easier control.

You might want to structure your .Net calls to run in the background and maintain communication if needed. Note that a background operation on a multi-core machine running the OS and VEE should be ok, else prioritize your multi-core “stuff” So essentially what the .Net code will end up, is a driver. If one exist, use it within your .Net.

You may also create a periodic “event” that pulls and puts whatever data you need, else use the protocol. VEE 7.0 and above should allow these event driven objects.

I know, this looks like a lot of effort. The .Net stuff is a piece of cake within the Visual Studio; the VEE hooks are probably easiest by using one of the examples. I would expect about one (1) man week of effort due to the nature of your problem, you need a code definition period, build code, debug, test, repair, and release. Sounds like at least a week to me, maybe two (2) weeks depending upon the Engineer.

Rufus

_____

From: S Wood [mailto:sfwood@harbornet.com]
Sent: Thursday, September 20, 2007 12:49 PM
To: VRF
Subject: [vrf] Multicore processors

Thanks to all,

I will let you know how it works out and what problems I run into. When I get the system running with the OS prioritizing everything, then I will try assigning processors and let everyone know how that works out also.

Thanks,

Steve

----- Original Message -----

From: HYPERLINK "mailto:Corey.Wills@bnsf.com"Wills, Corey D

To: HYPERLINK "mailto:vrf@agilent.com"VRF

Sent: Thursday, September 20, 2007 9:33 AM

Subject: RE: [vrf] Multicore processors

I would try it first without setting processor affinity or process priority. No sense messing with that stuff unless you really, really need it.

Regarding question 2, I really don't know. I'm certainly no .NET expert. I'd bet you can do it through a windows API call.

Corey

_____

From: S Wood [mailto:sfwood@harbornet.com]
Sent: Thursday, September 20, 2007 11:07 AM
To: VRF
Subject: [vrf] Multicore processors

Corey, thanks for the information - you can't beat hands on experience.

I am considering using two USB cards and two identical VEE programs, each calling a "C" routine to process the data from one laser as you suggested. A couple of quick questions:

1) If I have a separate "C" routine to reduce the data from each laser, would that make it worthwhile to allow the individual "C" routines to set a higher affinity for individual processors during the data reduction, or do you still feel that XP would do a better job of prioritizing the core usage?

2) I use the company intranet for post test data transfer to a server, but the company intranet has a habit of randomly grabbing any online computer for security downloads, so I have to disconnect the data acquisition machines during testing. Does dot.net have functions that allow VEE to programmatically disconnect and reconnect to a LAN?

Thanks,

Steve

---
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: 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: Rufus.Warren@herley.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".
Like • Show 0 Likes0
Actions
VRFuser Sep 21, 2007 7:16 AM
Mark Correct
Correct Answer
Warren, thanks for the information and direction.

It will undoubtedly be at least a months work for me since I have to come up to speed on .Net, windows operations, and using both with VEE. However, I have the time before this test runs, so now is the time to learn it. Hopefully, most of it will carry over to Vista when that time comes.

Steve

From: HYPERLINK "mailto:Rufus.Warren@Herley.Com"Warren, Rufus

Use the right tool for the right job.

If you wish to take advantage of a multi-core processor like a duo or quad and wish to continue to use VEE try the following:

Build your primary operating code within VEE. Structure is important.
Build your multi-core routines within .Net.
Drop your .Net into VEE as a stand alone module that updates either a memory location visible to VEE or a disk file.

Since the .NET code would be standalone and free running within VEE a file would be easier, but good attention to structure will keep your mod callable. I like a single call. You might want your .Net to have a protocol for easier control.

You might want to structure your .Net calls to run in the background and maintain communication if needed. Note that a background operation on a multi-core machine running the OS and VEE should be ok, else prioritize your multi-core “stuff” So essentially what the .Net code will end up, is a driver. If one exist, use it within your .Net.

You may also create a periodic “event” that pulls and puts whatever data you need, else use the protocol. VEE 7.0 and above should allow these event driven objects.

I know, this looks like a lot of effort. The .Net stuff is a piece of cake within the Visual Studio; the VEE hooks are probably easiest by using one of the examples. I would expect about one (1) man week of effort due to the nature of your problem, you need a code definition period, build code, debug, test, repair, and release. Sounds like at least a week to me, maybe two (2) weeks depending upon the Engineer.

Rufus

---
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".
Like • Show 0 Likes0
Actions

vrf Multicore processors

Outcomes

Related Content

Recommended Content