Orin writes: > If you use those, you have to lock the thread you are timing to one > CPU/Core as the performance counters are per CPU/Core and can get > out of step. Or you can force your thread onto one CPU for the > QueryPerformanceCounter call. This seems to be a bad idea to me as > it would add an indeterminate time before querying the counter > (indeterminate as if you are running on a different CPU, the OS > would have to switch to the one you requested).
In the WWV3 program I posted about some time ago, I use these calls to precisely calculate sleep times between second pulses, with excellent results (accurate to within human perception, not sure about microsecond accuracy). This does not mean that the timing cannot be temporarily off for one beep, but overall it is extremely precise. This was the only solution I could find for getting the sleep times correct, since they vary from one second to the next depending on how much time the program actually slept on the previous call (Windows does not guarantee that sleep times will be exact). The resolution for sleeping is also one millisecond, as I recall, and you need better timing than that in order to keep the beeps consistent. Generally, though, if you don't have an application or system function stalling the system, and the hardware is fast enough, you should be able to get away with all sorts of real-time use, as long as you accept that one day the machine might miss something (preferably not during a Cat III ILS approach). -- Anthony _______________________________________________ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.