Subject: Re: sysconf _SC_CLK_TCK bug?
To: Perry E. Metzger <perry@wasabisystems.com>
From: Ben Harris <bjh21@netbsd.org>
List: tech-userlevel
Date: 06/17/2002 15:54:58
On 17 Jun 2002, Perry E. Metzger wrote:

> Ben Harris <bjh21@netbsd.org> writes:
> > In article <87hek2rhal.fsf@snark.piermont.com> you write:
> > >It appears that sysconf(_SC_CLK_TCK) has a bug -- or at least that the
> > >implementation is, er, "deficient".
[...]
> > There doesn't seem to be any requirement for it to correspond to any
> > hardware concept, so our behaviour, while strange, is conforming.
>
> Unfortunately, the call is the only way for applications like ogle to
> guess what the resolution of calls like nanotime is.

Urgh.  clock_getres() and clock_gettime() would be more appropriate for
that, but we implement clock_getres() wrongly as well so I can't really
complain.

> > Be aware that times() returns its results in _SC_CLK_TCK units, so you need
> > to ensure that it stays in sync.
>
> Actually, according to the documents, it returns things in the fully
> unrelated CLOCKS_PER_SEC unit.

Are you sure?

<http://www.opengroup.org/onlinepubs/007904975/functions/times.html> says:
#   All times are measured in terms of the number of clock ticks used.
and in the APPLICATION USAGE (informative):
#   Applications should use sysconf(_SC_CLK_TCK) to determine the number of
#   clock ticks per second as it may vary from system to system.

Nowhere does it mention CLOCKS_PER_SEC.  The normative text in 1003.1-1996
is identical, and times(3) agrees.

You may be getting confused with clock(), which also uses clock_t, and
_does_ use CLOCKS_PER_SEC units.

> > More awkwardly, 1003.1-1996 says that CLK_TCK and sysconf(_SC_CLK_TCK) must
>
> I'm basing things on the brand new SuS3 -- i.e the new POSIX (as of a
> few months ago), not the old.

OK.  I wasn't sure that the old one could be considered to be
comprehensively dead just yet.

> > be the same, so you'll have to mess around a bit to deal with
> > dynamically-linked applications that have the current value of CLK_TCK
> > burned into them
>
> I think it is fine to leave them alone. They're no more wrong tomorrow
> than they were today.

Erm, at the moment they work, because our times() agrees that CLK_TCK is
the right unit to use.  See lib/libc/gen/times.c.  If you change the value
of CLK_TCK used by times(), then you'll break applications compiled with
the old value.

Incidentally, another potential problem if you care about 1003.1-1996 is
that it says that clock_t must be able to hold 24 hours' worth of clock
ticks.  This limits you to about 23000 clock ticks per second if it's a
signed 32-bit type (which it is on NetBSD/alpha).  This requirement seems
to have been dropped in 1003.1-2001.

-- 
Ben Harris                                                   <bjh21@netbsd.org>
Portmaster, NetBSD/acorn26           <URL:http://www.netbsd.org/Ports/acorn26/>