Comments on: What time 18446744073709550.000 means

By: Tim Bunce

Tim Bunce — Sat, 09 Jan 2010 22:56:42 +0000

That clock_gettime man page says “The CLOCK_PROCESS_CPUTIME_ID and CLOCK_THREAD_CPUTIME_ID clocks are realized on many platforms using timers from the CPUs (TSC on i386, AR.ITC on Itanium). These registers may differ between CPUs and as a consequence these clocks may return bogus results if a process is migrated to another CPU”

I think “may return bogus results” means that CLOCK_PROCESS_CPUTIME_ID and CLOCK_THREAD_CPUTIME_ID can appear to ‘go backwards’ if a process is migrated to a different cpu.

By: Mark Callaghan

Mark Callaghan — Sat, 09 Jan 2010 00:29:04 +0000

And this describes the broken behavior in CLOCK_THREAD_CPUTIME_ID and CLOCK_PROCESS_CPUTIME_ID — http://linux.die.net/man/3/clock_gettime. I have no idea what values are returned by them, but CPU time can’t go backwards.

By: Mark Callaghan

Mark Callaghan — Sat, 09 Jan 2010 00:25:06 +0000

Why would CLOCK_THREAD_CPUTIME_ID go backwards? It isn’t a wall clock timer, CLOCK_REALTIME and CLOCK_MONOTONIC do that. Ticks/nanoseconds/useconds of CPU time consumed by a process or thread should never go backwards. I think this is a bug in glibc or the Linux kernel.

By: peter

peter — Wed, 20 May 2009 16:45:45 +0000

Vadmin – do you know why Google patches do not use monotonic clock in their patches for wall clock timing ?

By: peter

peter — Wed, 20 May 2009 16:45:09 +0000

Tim,

I think math wise you’re right. However on the practical measures dealing with the huge values (not small negative values) is quite inconvenient. We also mainly use this for things like query execution time etc where the gain of accuracy by using negative values is not worth loss of convenience.

By: foo

foo — Tue, 19 May 2009 22:02:00 +0000

peter,

a monotonic clock won’t go backwards and it probably provides equal or better performance when compared to the other clocks supported by clock_gettime.

By: http://blog.timbunce.org/

http://blog.timbunce.org/ — Tue, 19 May 2009 21:23:44 +0000

Vadim. I believe the clocks are synchronized, just not as frequently as we’d like so they drift slightly. I had a link that, as I recall, explained that, but it doesn’t work now (http://webnews.giga.net.tw/article/mailing.freebsd.performance/710).

Re your analogy, imagine you have two watches (2 cpus) and each time you measure an interval you pick a watch at random (thread switched to different cpu). Over thousands of measurements you’ll get a more accurate total if you don’t discard negative durations.

By: Vadim

Vadim — Tue, 19 May 2009 17:28:28 +0000

TimBunce,

It is two different timers. They are not synchronized. If we get negative time from two different clocks I do not see why we should add this time to total time, it has no good information.
It’s like you measure time for runner and measure start time by your watches and measure finish time by your friend’s watches, and difference between both watches is unknown.
It may happen your friend’s watches is slower by XYZ sec. And by your watches runner started at 10:54 and by your friend’s watches he finished at 10:37.
By subtracting you get -0:17, but does it really have any sense ?

By: Shlomi Noach

Shlomi Noach — Tue, 19 May 2009 17:24:57 +0000

@Guillaume – thanks!

By: http://blog.timbunce.org/

http://blog.timbunce.org/ — Tue, 19 May 2009 16:51:27 +0000

Barron, I was referring to the underlying negative values that could arise from the clock_gettime() calls in the original article. The fact they’re presented as a huge positive my mysqld is obviously a bug.