[ntp:questions] Re: Monitoring the leap second tonight
n05W52+mgk25 at cl.cam.ac.uk
Sun Jan 1 14:52:57 UTC 2006
Hans =?iso-8859-1?Q?J=F8rgen?= Jakobsen <hjj at wheel.dk> writes:
|> >> http://www.cl.cam.ac.uk/~mgk25/time/leap/timelog.c
|> > But what about non X86 arch?
|> Some hack needed on Solaris sparc:
|> bash-2.03$ gcc timelog.c
|> timelog.c: In function `read_tsc':
|> timelog.c:44: unknown register name `edx' in `asm'
|> timelog.c:44: unknown register name `eax' in `asm'
You obviously need to undef HAVE_PENTIUM_TSC if you don't have one.
Can't think of an easy portable compile-time test for that one.
|> timelog.c: In function `main':
|> timelog.c:113: `CLOCK_MONOTONIC' undeclared (first use in this function)
|> timelog.c:113: (Each undeclared identifier is reported only once
|> timelog.c:113: for each function it appears in.)
|> timelog.c:114: `CLOCK_PROCESS_CPUTIME_ID' undeclared (first use in this function)
|> timelog.c:115: `CLOCK_THREAD_CPUTIME_ID' undeclared (first use in this function)
OK, fixed. I've added lots of #ifdef's using the POSIX macros
_POSIX_MONOTONIC_CLOCK, _POSIX_CPUTIME, _POSIX_THREAD_CPUTIME.
Even this little test routine has now ended up as the sort of #ifdef
spaghetti junction that makes every POSIX committee proud ... :-(
In principle, clock_gettime() is a far more sensible API
function than gettimeofday(). But the sad state of support
of clock_gettime() does not yet make it a very attractive
substitute for the ubiquitously available gettimeofday().
I see some homework for glibc and kernel developers here!
Actually, I see no reason whatsoever for why clock_gettime() should be
implemented in the kernel as a system call. All the kernel needs
to provide is to map into user space the conversion parameters
between the hardware clock and the various different POSIX clock
types. It also must grant user space direct read access to the clock
hardware. Then, API calls for querying the time will no longer
add the entire kernel context switch overhead as noise to their
measurements. The implementation of clock_gettime() and gettimeofday()
should be as fast and predictable as possible; both of these
requirements speak strongly against involving the kernel directly.
Markus Kuhn, Computer Laboratory, University of Cambridge
http://www.cl.cam.ac.uk/~mgk25/ || CB3 0FD, Great Britain
More information about the questions