If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
Multi-cpu machine, ProcessorAffinity, and process spike on wrong CPU question??
We are writing an application that does some heavy spectrometer data
acquisition and the machine we ship with the software is a dual CPU Intel based PC. We run Windows XP Pro SP2 there are multiple exe/dll that are part of our software package. We want the data acquisition software to run on one of the CPUs and we want ALL other processes to run on the other CPU. We wrote a service that watches the processes and sets the affinity to the correct cpu CurProc.ProcessorAffinity = (IntPtr)0x0001; the works.......mostly. What I'm seeing is that if I move a window of any running application (I'm talking something as small as minimize a window) I see a CPU spike ON THE WRONG CPU!!!! This is affecting the data acquisition. Just moving a window?? I guess I have multiple questions a. What's going on? b. Is there a different/better way to get all the processes to run on one of the CPU and this one program to run on the other? c. Would Win3K be any different? thanks mike |
Ads |
#2
|
|||
|
|||
There are several issues here to consider, the major being you can't control
which CPU the OS is going to use when you move, minimize or maximize a window - that my friend is an OS function and as such, normally it will pick the CPU with the lowest utilization. Secondly, what type of CPU's are they, by that I mean are they hyperthreaded CPU's. If so, and hyperthreading is active, you are actually dealing with 4 CPU's as far as XP is concerned. Lastly you need to remember when addressing hardware, everything is relative to 0, so on a 2 CPU system, the first CPU is CPU0, the second is CPU1, same with harddrives, video adapters, etc. In a hyperthreaded dual CPU setup, I've not really studied whether CPU0 and CPU1 are in the same physical CPU, or if CPU0 and CPU2 are in one and CPU1 and CPU3 are in the other. And not to mention the new dual core CPU's, along with Intel's intention on releasing dual core CPU's with hyperthreading enabled. So how's that going to work, with twin dual core hyperthreaded CPU's - will it see 8 CPU's total, CPU0 through CPU7, or will the OS be limited? I guess we'll wait and see. -- Star Fleet Admiral Q @ your Service! http://www.google.com Google is your "Friend" "Michael Howes" wrote in message ... We are writing an application that does some heavy spectrometer data acquisition and the machine we ship with the software is a dual CPU Intel based PC. We run Windows XP Pro SP2 there are multiple exe/dll that are part of our software package. We want the data acquisition software to run on one of the CPUs and we want ALL other processes to run on the other CPU. We wrote a service that watches the processes and sets the affinity to the correct cpu CurProc.ProcessorAffinity = (IntPtr)0x0001; the works.......mostly. What I'm seeing is that if I move a window of any running application (I'm talking something as small as minimize a window) I see a CPU spike ON THE WRONG CPU!!!! This is affecting the data acquisition. Just moving a window?? I guess I have multiple questions a. What's going on? b. Is there a different/better way to get all the processes to run on one of the CPU and this one program to run on the other? c. Would Win3K be any different? thanks mike |
#3
|
|||
|
|||
Heavy "Spectrometer Data" Acquisition. It would help to know the type of
interface being used, the volume of data and rate at which it is being transmitted along with anything else that you care to share. I suggest you solve this issue at the lowest level in the system that you can so as to facilitate the highest degree of reliability. Using SetProcessAffinity is not the way to go... There are two major issues here. 1. You are trying to use SetProcessAffinity to overide Windows own thread scheduler. It is the scheduler that determines which CPU a process *thread* runs on when it activates it. SetProcessAffinity is a bit of an odd-ball function at this point in time - it has its uses, but in general should not be used (IMHO) except for diagnostic reasons. This is quite futile. You will need to lock the entire machine down to ensure that no unexpected processes start and so end up at least for a moment on the wrong CPU. Your application will do disk IO's - if any windows task concurrently runs that does IO's and your app just happens to try to compete, then process affinity or not, it will loose. Rather than battling SetProcessAffinity, IMHO you are better to address why your application a) has to read data in such a critical manner, and b) ways to remove this criticality. 2. You have an application that is sampling data and trying to do so in psuedo real-time on an operating system that is not designed for real-time operations. You are far better off solving the issue as to why your process is not sampling the data required when required within that application scope than anywhere else. The method for solving this problem can vary quite a lot and depends on the type of hardware interface and API's you are using to communicate with the hardware. There are two methods to get data: Polling, or Interrupt. In a polling scenario the application processes continuously looking to see if there is new data. This consumes CPU, often mistakenly includes Sleep statements in code (a really bad thing to do), and often results in missed data as the program does not sometimes see new data before it has gone. In the interrupt driven method, when new data arrives, a driver above the hardware device receives a hardware interrupt that says "New Data" and that driver then "immediately" reads the new data, adds it to a queue of data to be processed, and then Sets an Event on a Handle for your application to respond to to process that data in a timely fashion. Because the data is added in the very first instance to a queue - a fast short operation, it is read from the device before it is lost and the time critical aspect of the process is overcome because the data is now in a queue of data to be processed for this device by your application. Device drivers are small, locked in memory (usually), and run at a high priority. Applications are very large in comparison, are not locked in memory, and run at a much lower priority competing with each other for CPU and other resources - with device drivers always being able to leap in at that higher priority to do those time critical things. If your hardware is custom - say a custom PCI interface, then you will need to write a device driver that in turn will awaken your process via various stock windows methods EG interrupts at the low level from the PCI card to the driver, and perhaps signals using Handles at a higher level above the device driver. This can be a horribly daunting process. Somehow you have got as far as getting the data in - with some reliability. So you are using a device driver or other method (API's, bypassing IO Ports using a Psuedo Driver) to achieve this - this is where things need to be reviewed. If the hardware is interfaced via say COMM port or LPT port then things can be "simpler". In using these IO devices, you may be using stock windows API's, but by the sounds of it not in the best way. There are many interfaces that require for example full LPT port access for bidirectional communications with devices such as AD converters (I have built several). If you are using a custom device driver for full LPT or COMM port access then you should review how it is architected and look again at implementing an ability for the driver to signal an event that *must* be serviced by software using Handles (as an example). In your application at a higher level you will need to amend the code to WaitForEvent and process those events efficiently and in a timely manner without the risk of the processing itself overrunning the next event - you may need to use multithreading to achieve this. The principles are the same for other methods of device connection - USB, Firewire, Ethernet. It breaks down to where in the current IO model can you change the code from Polling (yes I am guessing) to an Interrupt / Set Event or other synchronised method. This response does not constitute the answer to your problem, I have tried to only raise to your attention the possible methods you may wish to use to address the issue. None of this is beginners stuff. If your application is written in C++ or C, you may wish to head on over to the microsoft.public.vc.mfc news group and post your question there. There are many knowledgable people over there that will be able to point you in exactly the right direction. If your application is not written in C++, then it will still be using Windows API's under the hood and the solution will be to invoke the correct use of the most appropriate API's in you language so the above news group will still be useful - pay attention to similar posts answered by Dr Joseph Newcomer. HTH - Tim "Michael Howes" wrote in message ... We are writing an application that does some heavy spectrometer data acquisition and the machine we ship with the software is a dual CPU Intel based PC. We run Windows XP Pro SP2 there are multiple exe/dll that are part of our software package. We want the data acquisition software to run on one of the CPUs and we want ALL other processes to run on the other CPU. We wrote a service that watches the processes and sets the affinity to the correct cpu CurProc.ProcessorAffinity = (IntPtr)0x0001; the works.......mostly. What I'm seeing is that if I move a window of any running application (I'm talking something as small as minimize a window) I see a CPU spike ON THE WRONG CPU!!!! This is affecting the data acquisition. Just moving a window?? I guess I have multiple questions a. What's going on? b. Is there a different/better way to get all the processes to run on one of the CPU and this one program to run on the other? c. Would Win3K be any different? thanks mike |
Thread Tools | |
Display Modes | |
|
|