python - time.time() drift over repeated calls -


i getting timestamp every time key pressed this:

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

(getch answer).

i verifying timestamps against audio recording of me typing keys. after lining first timestamp waveform, subsequent timestamps drift slighty consistently. mean saved timestamps later keypress waveforms , later , later time goes on.

i reasonably sure waveform timing correct (i.e. recording not fast or slow), because in recording included ticking of accurate clock lines second markers.

i aware there unavoidable limits accuracy of time.time(), not seem account i'm seeing - if equally wrong on both sides acceptable, not want gradually diverge more , more truth.

why seeing drifting behaviour , can avoid it?

just solved using time.monotonic() instead of time.time(). time.time() seems use gettimeofday (at least here does) apparently bad measuring walltime differences because of ntp syncing issues:

gettimeofday() , time() should used current time if current wall-clock time want. should never used measure time or schedule event x time future.

you aren't running ntp on wristwatch, won't jump second or 2 (or 15 minutes) in random direction because happened sync against proper clock @ point. ntp implementations try not make time jump this. they instead make clock go faster or slower drift correct time. while it's drifting either have clock that's going fast or slow. it's not measuring passage of time properly.

(link). measuring differences between time.time() calls bad idea.


Comments

Popular posts from this blog

html - Firefox flex bug applied to buttons? -

html - Missing border-right in select on Firefox -

c# - two queries in same method -