Archived from groups: microsoft.public.windowsxp.general,microsoft.public.windowsxp.hardware (
More info?)
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" <mhowes@xfortebio.com> wrote in message
news:%23xADMsXjFHA.3164@TK2MSFTNGP15.phx.gbl...
> 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
>
>
>
Facebook
Twitter
Instagram