I have a perl script using Time::HiRes (in particular its "time" function) to write a log file of elapsed times (in fractional seconds) for key strokes, and this is being done while an audio recording process is going on. (Each key stroke brings up a new phrase on the display, and a person reads the phrase aloud.)
So, each keyboard input event relates to (immediately precedes) a spoken utterance in the audio file, and the plan is that the time stamps in the log file will match up with audio time offsets, so that the key-stroke times will identify the locations of the utterances in the recording.
The problem is that the values returned by Time::HiRes on this windows/cygwin setup appear to be moving along faster than "real" elapsed time, as marked by the audio data. For example:
Since the keyboard clicks are audible in the audio, and the log file includes the text for each phrase being displayed, I can tell that the log file times and audio locations match pretty well at the beginning of a session, but for an utterance that occurs at 300.0 sec from the start of the audio file, the corresponding log file time stamp shows 302.5 (roughly) -- that is, Time::HiRes is gaining about half a second for every minute of elapsed time.
The man page for the module contains this little gem:
... in Win32 (and derived platforms like Cygwin and MinGW) the Time::HiRes::time() may temporarily drift off from the system clock (and the original time()) by up to 0.5 seconds. Time::HiRes will notice this eventually and recalibrate.
Has anyone been bothered by this "feature"? Can anyone elaborate on what sort of behavior I should expect (e.g. sudden/unpredictable "re-alignments" in the middle of a session log file, or a consistent pattern of resets at specific intervals)? Is there a sensible solution or workaround for getting accurate timing data?
In reply to Time::HiRes (un)reliability in Windows/Cygwin ?? by graff
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |