in reply to Time::HiRes (un)reliability in Windows/Cygwin ??

The way I read the (uncut) man page quote leads me to believe the mentioned drift only occurs when "adjusting the system clock (either manually or by services like ntp)".

At I ran the following code: 

perl -le"use Time::HiRes qw( time ); print time while <>

[download]

I pressed enter at 4:39:00, 4:44:00 and 4:56:00. 

1185395940.27216

1185396239.78586

1185396960.49883

[download]

Time 1 and Time 2:
Clock time difference: 300 seconds
HiRes time difference: 299.5137 seconds
Drift: 0.09726 HiRes second per Clock minute

Time 1 and Time 3:
Clock time difference: 1020 seconds
HiRes time difference: 1020.22667 seconds
Drift: 0.01333 HiRes second per Clock minute

You mentioned a drift of 0.5 HiRes second per Clock minute. I am simply not seeing that. The error is surely due to the variance in my response time.

By the way, old versions of Time::HiRes (< 1.53) had notorisouly bad resolution on Windows. Are you using something recent?

Replies are listed 'Best First'.
Re^2: Time::HiRes (un)reliability in Windows/Cygwin ??
by graff (Chancellor) on Jul 25, 2007 at 22:38 UTC
    Thanks for the info -- esp. about the version issue (I'll need to check into that, but the machine is not close to my desk).

    I also tried a one-liner test similar to what you showed, and I got results similar to yours -- that is, I was not able to replicate the problem when I tried the simplest possible means to demonstrate it.

    Naturally, the overall situation is more complicated -- the script that is writing the log file is actually a Perl/Tk app (so that the phrase to be read aloud is presented in a nice big font), and so far I'm just assuming that the sampling rate of the audio file is "accurate" (supposed to be 16 kHz, though I'm not sure if this is done via downsampling from something like 44.1). Uncertainty abounds...

[reply]
      so far I'm just assuming that the sampling rate of the audio file is "accurate"

      It might be worth verifying that. What audio recording hardware are you using? In fact, there are some particularly bad soundcards out there, like this one, for example, which could approximately account for the drift you're observing... Most cards are significantly better, though (by orders of magnitude), so this may not necessarily be the problem in your case. But how would you know, unless you've actually measured it...?

      A relatively easy way to check would be to record the ticking of a reasonably accurate clock (with an analog display), and then verify that the peaks of the recorded waveform stay in sync with what the audio software reports based on the assumed sample rate. (Even cheap quartz wrist watches typically have of drift of less than one second per day, so that should be a sufficiently precise time reference for the purpose at hand...)

      Incidentally, when I was working in psycholinguistic/ERP research, we were using similar experimental setups, to present stimuli, and such... And from those experiences I can confirm that sample rate inaccuracy can in fact become a problem in special cases like the one you're describing.  That was more than a decade ago, though. Hardware might actually have improved since then — or maybe not...

[reply]

In Section Seekers of Perl Wisdom