[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:
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...
More information about the Linux-audio-dev