monotonic_clock questions

[C. SB]

Hi,
I read the (very) interesting article at http://blog.habets.pp.se/2010/09/gettimeofday-should-never-be-used-to-measure-time
, and checked the library you have up on github... Some questions come to mind:

1- for implementations using clock_gettime(), why use CLOCK_MONOTONIC and not CLOCK_MONOTONIC_RAW ? I understand the difference... but I guess the answer is "it depends what the user needs"... In my code I #ifdef CLOCK_MONOTONIC_RAW, #else fall back to CLOCK_MONOTONIC. I think it would also be possible to detect this at runtime (see point #3 below!)

2- Re the choice of "double" for return values... if my reading of <limits.h> is correct, with only 10 digits, measurement of short durations could be a problem: consider a case where the system has been running for some time and clock_get_dbl() returns say 100.0E3. User runs some code for 10us, then the next call to clock_get_dbl() would also return 100.0E3 since it's dropping the 11th significant digit (if I'm counting this correctly) ? 100E3 seconds is 27h, not unusual for system uptimes. I think I busted 2000h uptime on my laptop once p-)

All this to say, I wonder if double is the best choice for return values. Unfortunetaly I don't have great suggestions. In my code I return microseconds as unsigned long long, (>= 64bits), leaving the caller do the math for seconds if required. I reasoned: system calls (whether QPC on win*, or clock_gettime() on *nix) cannot be expected to take much less than 1us... It's a "bigger hammer" solution, but it should provide >500 years of peace of mind !

3- Minor point : a clock_init() function, that discovers capabilities & scaling factors (especially for win*), could make the clock_get_dbl() implementations cleaner and have less overhead... The drawback of course is that the user would then need to add a call to clock_init() somewhere in their code.

Thanks for the very interesting blog post. A lot of devs should really, really read it. Now every time I see gettimeofday() calls, I see Evil waiting to manifest itself !!

Regards,
Chris

[tho...@habets.se]

On Wed, 15 Apr 2015 17:50:16 +0200, "C. SB" <belt...@email.com> said:
> 1- for implementations using clock_gettime(), why use CLOCK_MONOTONIC and not
> CLOCK_MONOTONIC_RAW ? I understand the difference... but I guess the answer is "it
> depends what the user needs"... In my code I #ifdef CLOCK_MONOTONIC_RAW, #else
> fall back to CLOCK_MONOTONIC. I think it would also be possible to detect this at
> runtime (see point #3 below!)

You can't detect intention at runtime, but it would be nice to detect
availability at runtime, but I don't think it's possible.
CLOCK_GETTIME_RAW is Linux-specific,
so we can't just assume the number it's defined to is constant.

But it should be stable. If it's available at compile time it should
work at runtime. This is something this library should wrap.

> 2- Re the choice of "double" for return values... if my reading of <limits.h> is
> correct, with only 10 digits, measurement of short durations could be a problem:
> consider a case where the system has been running for some time and clock_get_dbl()
> returns say 100.0E3. User runs some code for 10us, then the next call to
> clock_get_dbl() would also return 100.0E3 since it's dropping the 11th significant
> digit (if I'm counting this correctly) ? 100E3 seconds is 27h, not unusual for
> system uptimes. I think I busted 2000h uptime on my laptop once p-)

Yup, that sounds better. I've filed
https://github.com/ThomasHabets/monotonic_clock/issues/3
to make 64bit nanoseconds functions too.

I'll get right on that.

> All this to say, I wonder if double is the best choice for return values. Unfort
> unetaly I don't have great suggestions. In my code I return microseconds as unsi
> gned long long, (>= 64bits), leaving the caller do the math for seconds if requi
> red. I reasoned: system calls (whether QPC on win*, or clock_gettime() on *nix)
> cannot be expected to take much less than 1us... It's a "bigger hammer" solution
> , but it should provide >500 years of peace of mind !

64bit should allow for 584 years, no?
2^64/(86400*10^9*365)=584

> 3- Minor point : a clock_init() function, that discovers capabilities & scaling
> factors (especially for win*), could make the clock_get_dbl() implementations cleaner
> and have less overhead... The drawback of course is that the user would then
> need to add a call to clock_init() somewhere in their code.

There's only overhead on the first call. I don't think this is as
problem. It should do it thread-safely on the first call though. Not fixed yet.

> Now every time I see gettimeofday() calls, I see Evil waiting to manifest itself !!

Then I have succeded in what I intended. Thanks!