Folks, in my application I’m using
clock_gettime(CLOCK_MONOTONIC) in order to measure the delta time between frames (a typical approach in gamedev) and from time to time I’m facing a strange behavior of
clock_gettime(..) – returned values occasionally are not monotonic (i.e prev. time is bigger than current time).
Currently, if such a paradox happens I simply skip the current frame and start processing the next one.
The question is how can this be possible at all? Is it a bug in Linux POSIX implementation of
clock_gettime? I’m using Ubuntu Server Edition 10.04 (kernel 2.6.32-24, x86_64), gcc-4.4.3.
man clock_gettime says:
CLOCK_MONOTONIC_RAW (since Linux 2.6.28; Linux-specific)
Similar to CLOCK_MONOTONIC, but provides access to a raw hardware-based time that is not subject to NTP adjustments.
CLOCK_MONOTONIC_RAW is not subject of NTP adjustments, I guess
CLOCK_MONOTONIC could be.
We had similar problems with Redhat Enterprise 5.0 with 2.6.18 kernel and some specific Itanium processor. We couldn’t reproduce it with other processor on the same OS. It was fixed in RHEL 5.3 with slightly newer kernel and some Redhat patches.
Looks like an instance of
commit 0696b711e4be45fa104c12329f617beb29c03f78 Author: Lin Ming <[email protected]> Date: Tue Nov 17 13:49:50 2009 +0800 timekeeping: Fix clock_gettime vsyscall time warp Since commit 0a544198 "timekeeping: Move NTP adjusted clock multiplier to struct timekeeper" the clock multiplier of vsyscall is updated with the unmodified clock multiplier of the clock source and not with the NTP adjusted multiplier of the timekeeper. This causes user space observerable time warps: new CLOCK-warp maximum: 120 nsecs, 00000025c337c537 -> 00000025c337c4bf
See here for a patch. This was included into 184.108.40.206, but may not have been backported by the Debian team(?). You should check it out.
Sure sounds like a bug to me. Perhaps you should report it in Ubuntu’s bug tracker.
It’s a linux bug. No ajustment in a monotonic clock can make it go backwards. You’re using a very old kernel and a very old distribution.
Edit: are you sure you need to skip the frame ? If you call clock_gettime again, what happens ?