Per,
You make good points, but from the man page for the gettimeofday(),
clock_gettime() and others it would be impossible to deliver the values
without intimate kernel participation. The library routines may be
wrappers, but the functionality is performed by kernel primitives in
both Solaris and FreeBSD. I don't know if this is true for Linux; but if
not, that is another reason for switching to FreeBSD.
It doesn't matter if either of the routines returns something with less
precision than the timespec or timeval; the daemon measures the
precision directly.
My comment on library functionality is based on the assumption that if
gettimeofday() happens to appear in different libraries, it designates
the same routine and performs the same function.
I don't trust the claimed resolution either; that's why the daemon
measures it directly. But, understand the NTP precision value is
measured as the time to read the clock, not the resolution of the clock
itself. My Blade 1500 measures 400 ns; my 3.8 GHz Pentium FreeBSD
measures 1900 ns; my old Sun IPC running SunOS 4.3 measured 42000 ns.
Dave
Per Hedeland wrote:
In article <[EMAIL PROTECTED]> "David L. Mills"
<[EMAIL PROTECTED]> writes:
The NTP get_systime() routine calls one of three library routines,
clock_gettime(), getimeofday() and getclock(), depending on
autoconfigure. At least the first two and probably the last are kernel
system calls and don't depend on other routines.
Hm, how can you (or ntpd) determine whether (say) clock_gettime() on any
given OS is an actual system call or just a library wrapper around a
gettimeofday() system call? Or (perhaps more likely) whether a "real
system call" clock_gettime() actually has a kernel-level implementation
that amounts to a wrapper around gettimeofday()?
There are obviously valid reasons to implement clock_gettime() even on a
system that can't actually produce better than microsecond resolution,
notably to provide a better interface than times() to get
CLOCK_MONOTONIC time stamps.
The clock_gettime() and
getclock() return nanoseconds in a timespec structure; the
gettimeofday() returns microseconds in a timeval structure. As these are
system calls, no matter what library they are in, they would operate the
same way.
The same way as what?:-) Clearly the definition of struct timespec or
struct timeval has no bearing on what the actual resolution of the
returned timestamp is - it's perfectly acceptable for both
gettimeofday() and clock_gettime() to return timestamps that have only
1/HZ resolution, or less. For gettimeofday(), we can only guess or
conduct experiments - for clock_gettime(), clock_getres() is supposed to
give the answer (yet another reason to implement clock_gettime() and
clock_getres()).
Someone else wrote (I think) that clock_get_res() on Linux simply
reported 1/HZ - I did a test and got an even worse result: On a system
running at HZ=1000, clock_get_res reported 10 ms! Anyway it's clearly
broken. On my FreeBSD 5.3, clock_getres() reports 280 ns - whether that
is correct I have no idea, but it sure isn't anywhere near 1/HZ (HZ=100
on this system).
--Per Hedeland
[EMAIL PROTECTED]
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
