tags:

views:

131

answers:

4

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

Thanks

+2  A: 

Try CLOCK_MONOTONIC_RAW.

Matt Joiner
+1  A: 

Sure sounds like a bug to me. Perhaps you should report it in Ubuntu's bug tracker.

caf
Bug trackers are nice, and so is submitting bugs (which everyone should do), but they're unpopular because programmers want fixes NOW. Generally upstream bugs aren't fixed until long after you've finished coding the majority of a project, and you have to support people who haven't upgraded the upstream libs for a long time anyway. :(
Matt Joiner
So sad, so true...
pachanga
+1  A: 

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.

Since 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.

Dmitry Yudakov
Thanks for the tip. Another lesson for me - never ever absolutely trust even the most reliable libraries :)
pachanga
+1  A: 

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 2.6.32.19, but may not have been backported by the Debian team(?). You should check it out.

Michael Foukarakis