Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW
 
PerlMonks  

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

by desemondo (Hermit)
on Jan 20, 2010 at 22:24 UTC ( #818577=note: print w/replies, xml ) Need Help??


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

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

  • Comment on Re^4: Unexpected Timing spikes using Time::HiRes

Replies are listed 'Best First'.
Re^5: Unexpected Timing spikes using Time::HiRes
by BrowserUk (Pope) on Jan 20, 2010 at 23:55 UTC

    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.
      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';
        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?


        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.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://818577]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (2)
As of 2020-01-18 12:22 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Notices?