in reply to Re: Unexpected Timing spikes using Time::HiRes
in thread Unexpected Timing spikes using Time::HiRes

indeed, that does seem to make a difference, only 11 out of 19,000 samples were unexpected using realtime priority on the perl.exe process running the script.

Interestingly however, the smallest 'error' was still 15.625ms... it didn't shrink it, only reduced the occurrance of it.
anyhow, thanks for the pointer - looks like i might have to just live with it. Cheers
  • Comment on Re^2: Unexpected Timing spikes using Time::HiRes

Replies are listed 'Best First'.
Re^3: Unexpected Timing spikes using Time::HiRes
by BrowserUk (Patriarch) on Jan 20, 2010 at 15:03 UTC

    My guess is that you are running this on an XP or 200x system?

    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
      Mixture of XP, 2000 and 2003. Is this another result/side-effect of windows' "evolved" multitasking model?...

[reply]

        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?

        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]

In Section Seekers of Perl Wisdom