2

I am getting a timestamp every time a key is pressed like this:

init_timestamp = time.time()
while (True):
    c = getch()
    offset = time.time() - init_timestamp
    print("%s,%s" % (c,offset), file=f)

(getch from this answer).

I am verifying the timestamps against an audio recording of me actually typing the keys. After lining the first timestamp up with the waveform, subsequent timestamps drift slighty but consistently. By this I mean that the saved timestamps are later than the keypress waveforms and get later and later as time goes on.

I am reasonably sure the waveform timing is correct (i.e. the recording is not fast or slow), because in the recording I also included the ticking of a very accurate clock which lines up perfectly with the second markers.

I am aware that there are unavoidable limits to the accuracy of time.time(), but this does not seem to account for what I'm seeing - if it was equally wrong on both sides that would be acceptable, but I do not want it to gradually diverge more and more from the truth.

Why would I be seeing this drifting behaviour and what can I do to avoid it?

Community
  • 1
  • 1
akxlr
  • 1,142
  • 9
  • 23
  • Have you tried `time.clock()`, on some systems, this is more accurate then `time.time()` – muddyfish Aug 19 '15 at 12:03
  • 2
    @muddyfish no, `time.clock()` would definitely be the wrong thing to use here. `time.clock()` is processor clock time (it won't advance if the program doesn't use any clock cycles), instead of wall clock time (`time.time()`). See also: http://pymotw.com/2/time/ – Lukas Graf Aug 19 '15 at 12:14
  • Ah, correction: On Windows `time.clock()` does in fact seem to be returning wall-clock seconds. *sigh* – Lukas Graf Aug 19 '15 at 12:16

2 Answers2

1

Just solved this by using time.monotonic() instead of time.time(). time.time() seems to use gettimeofday (at least here it does) which is apparently really bad for measuring walltime differences because of NTP syncing issues:

gettimeofday() and time() should only be used to get the current time if the current wall-clock time is actually what you want. They should never be used to measure time or schedule an event X time into the future.

You usually aren't running NTP on your wristwatch, so it probably won't jump a second or two (or 15 minutes) in a random direction because it happened to sync up against a proper clock at that point. Good NTP implementations try to not make the time jump like this. They instead make the clock go faster or slower so that it will drift to the correct time. But while it's drifting you either have a clock that's going too fast or too slow. It's not measuring the passage of time properly.

(link). So basically measuring differences between time.time() calls is a bad idea.

Community
  • 1
  • 1
akxlr
  • 1,142
  • 9
  • 23
  • the current cpython may use [`clock_gettime(2)`, `GetSystemTimeAsFileTime()`](http://stackoverflow.com/a/28574340/4279). Have you checked that `time.time()` drifts while `time.monotonic()` is accurate enough in your case? What is your OS, python version? – jfs Aug 20 '15 at 05:47
  • OSX, python 3.4.1. I am not getting any noticeable drift with `time.monotonic`, and `time.time` was definitely drifting. – akxlr Aug 20 '15 at 09:04
0

Depending on which OS you are using you will either need to use time.time() or time.clock().

For windows OS's you will need to use time.clock this give you will clock seconds as a float. time.time() on windows if I remember correctly time.time() is only accurate within 16ms.

For posix systems (linux, osx) you should be using time.time() this is a float which returns the number of seconds since the epoch.

In your code add the following to make your application a little more cross system compatible.

import os
if os.name == 'posix':
    from time import time as get_time
else:
    from time import clock as get_time

# now use get_time() to return the timestamp
init_timestamp = get_time()
while (True):
    c = getch()
    offset = get_time() - init_timestamp
    print("%s,%s" % (c,offset), file=f)
    ...
Matt Seymour
  • 8,880
  • 7
  • 60
  • 101