Re^4: Unexpected Timing spikes using Time::HiRes

[desemondo]

Mixture of XP, 2000 and 2003. Is this another result/side-effect of windows' "evolved" multitasking model?...

[BrowserUk]

I'm unable to reproduce your results on Vista, but it uses a different scheduling mechanism. It occassionally takes a little longer than 1 second to wake up, but only by 1 or 2 milliseconds at most. Even running at standard priority.

I think that what you are seeing is simply an affect of timing.

XP (and as far as I know 200x) use a hardware timer of approx. 15ms for the scheduler. If your process is due to wake up from it's 1 second sleep a few microseconds after another, cpu-intensive process gets it 15ms timeslot, then by the time your process next gets a chance to run, it will be 1.0015 + a little bit since the sleep was initiated.

Running at the highest priority means your process will get the next available timeslot, but it won't allow it to interrupt the current timeslot.

I'm not certain that's a convincing explanation, but it is the best I have.

Basically, trying to time anything to sub millisecond accuracy on a pre-emptive multi-tasking OS will inevitably sometimes be subverted by the scheduler allowing another task to run just when you want to collect your timing.

Depending what it is that you are trying to time--real-world events -v- code--then you might be better off using the cpus instruction timer.

Out of interest, which version of Time::HiRes are you running?

[desemondo]

many thanks, that does sound logical. The thing that I find unusal though is sometimes I get spikes above 15.625 - can you think of a reason that might cause that?

update:
Actually, I think I just figured it out, the spike of 265.625 is exactly 17 x 15.625 - so whatever process was in the way held onto the CPU for 17 timeslots past what the script was expecting, right?

Regarding Time::HiRes version, I'm using $VERSION = '1.9707';

[BrowserUk]

so whatever process was in the way held onto the CPU for 17 timeslots past what the script was expecting, right?

Make sense to me. Though it doesn't have to be a single process. It could be a mix of 2 more higher (or equal) priority tasks, that between them prevent yours getting back for 17 slots.

If you run it at standard priority and play some music or video at the same time you may see the frequency of the misses increase.

What is it that you are trying to time?