Re: [Question] CLOCKS_PER_SEC value

[Eric Blake <eblake at redhat dot com>]

On 08/22/2011 10:13 AM, Tim Prince wrote:
> On 8/22/2011 11:34 AM, Joon Hee Lee wrote:
> > Dear all,
> >
> > POSIX standard defines CLOCKS_PER_SEC value is 1000000.
> > However, the current value in newlib for ARM and THUMB, is 100.
> > I couldn't understand the reason to define CLOCKS_PER_SEC as 100.

There are two useful semantics for CLOCKS_PER_SEC.  One is the scaling 
factor for what units the clocks increment in, and the other is how many 
times the clock can be incremented in a second.  POSIX requires the 
former, the ARM code is apparently using the latter.

> > Could you let me know about the reason and wouldn't it be better to go
> > with the POSIX value?

It probably would be better to go with the POSIX value, but existing 
code relying on the old value may need to be adjusted.

> >
>
> I don't think it's our business to change a decision presumably made by
> the platform implementor. However, I'll point out that the actual
> resolution on a vast majority of existing machines is no better than 100
> CLOCKS_PER_SECOND, and it's probably more difficult to deal with that on
> platforms which don't support support a physical int_64 or good double
> support, as we're wasting a lot of bits with the posix definition.

POSIX does NOT require that CLOCKS_PER_SEC be the granularity of 
interrupts, only that it be the scaling factor expressing in which units 
clock ticks are represented in.  You are still permitted to round to the 
next point in time where you can actually achieve an interrupt (that is, 
if the value of 100 means that the current granularity is 10 
milliseconds, then switching to the POSIX-mandated CLOCKS_PER_SEC of 
1000000 means that requesting a usleep() for 1 microsecond would be no 
different than requesting a usleep for 10000 microseconds - both round 
up to 1 clock tick of 10 milliseconds).  And instead of the clock 
monotonically increasing by 1 step at a tick, it now monotonically 
increases by a step of 10000 at a tick.

--
Eric Blake   eblake@redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org