5 May
2011
5 May
'11
1:30 a.m.
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.
Then I tried clock_gettime(CLOCK_PROCESS_CPUTIME_ID, ..)
and it appears to be OK so far, giving me what I want - truly linear time.
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.
Any advice here, anyone seen this?
Also, when using Jack, is it advisable to choose the same
clock method as Jack is using (cycle, hpet, system)?
Thanks. Tim.
5 May
5 May
2:20 a.m.
On Wed, May 4, 2011 at 7:11 PM, Tim E. Real <termtech(a)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.
8:16 a.m.
On May 4, 2011 08:20:51 pm you wrote:
On Wed, May 4, 2011 at 7:11 PM, Tim E. Real
<termtech(a)rogers.com> wrote:
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-realtim…
and-clock-monotonic
http://stackoverflow.com/questions/3657289/linux-clock-gettimeclock-monoton…
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!
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.
5011
days inactive
5012
days old
linux-audio-dev@lists.linuxaudio.org
2 comments
2 participants
participants (2)
-
Paul Davis -
Tim E. Real