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

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.
"I'd rather go naked than blow up my ass"
  • Comment on Re^5: Unexpected Timing spikes using Time::HiRes

Replies are listed 'Best First'.
Re^6: Unexpected Timing spikes using Time::HiRes
by desemondo (Hermit) on Jan 21, 2010 at 01:49 UTC
    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';
[reply]
[d/l]
      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.
[reply]
        At present, i'm using it in a pair of simple 'ping' scripts.

        Now, before you say, I should just use Net::Ping or another varient, the reason I'm rolling my own is that I need to a 'ping' tool that goes to the top of the tcp stack, and not only halfway. (I have seen many issues where a server is hung but still responds to icmp pings.) Plus, I wanted to learn a bit more about how sockets and InterProcess communication work, by making my own.

        In troubleshooting a timing issue in another application, these scripts will hopefully rule out our network and point the finger at the application (or maybe the server...).

        (OT)
        Due to this apparent timeslot priority issue, is there any way to read from a non-blocking socket without sleeping? I've found that unless I sleep inside the socket-read loop, the CPU bleeds like crazy...
[reply]

In Section Seekers of Perl Wisdom