[LAD] Strange gettimeofday behaviour - out of order times.

Tim E. Real termtech at rogers.com
Thu May 5 05:57:58 UTC 2011


On May 4, 2011 08:20:51 pm you wrote:
> On Wed, May 4, 2011 at 7:11 PM, Tim E. Real <termtech at rogers.com> wrote:
> > I discovered gettimeofday occasionally gives me a time value
> >  which is less than a previous time value. The value is actually
> >  'out of order' and really belongs ahead of a few others,
> >  according to examined printouts.
> >
> > So I tried  clock_gettime(CLOCK_MONOTONIC, ..), same result.
>
> i believe you want CLOCK_REALTIME. however, if CLOCK_MONOTONIC is
> malfunctioning and you can prove it with a very small piece of code,
> the kernel guys will want to know.
>
> > Still checking some things, maybe there's a reason, the app's fault.
> > From what I've read gettimeofday is thread safe, but the incorrect
> >  time values are being read by the same thread always.
>
> gettimeofday() is subject to system time corrections (e.g. via NTP).
> it is never ever guaranteed to be monotonic.

Weird, CLOCK_REALTIME does it too. 
Only CLOCK_PROCESS_CPUTIME_ID does not.

Been reading, according to places like this:

http://stackoverflow.com/questions/3523442/difference-between-clock-realtime-
and-clock-monotonic

http://stackoverflow.com/questions/3657289/linux-clock-gettimeclock-monotonic-
strange-non-monotonic-behavior

CLOCK_MONOTONIC and CLOCK_MONOTONIC_RAW are not supposed to go backwards 
 but apparently CLOCK_MONOTONIC just might and CLOCK_MONOTONIC_RAW is better, 
 and CLOCK_REALTIME is less reliable than that.

However on that second page it mentions a kernel fix, more recent than mine.
Mine also doesn't seem to have CLOCK_MONOTONIC_RAW.

I am going to chalk it up to this older kernel, and test on my newer machine 
 and hope it vanishes...

In the meantime, I can make the code I'm working on tolerant. 
I'm just not sure how this affects the rest of the existing app code - 
 could this be the source of occasional bugs or have we just been lucky or
 is it already tolerant...

Thanks!





More information about the Linux-audio-dev mailing list