[ntp:questions] Re: ntpd transmit timestamp precision
David L. Mills
mills at udel.edu
Fri Feb 17 21:54:35 UTC 2006
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 <dt3bvu$m56$1 at dewey.udel.edu> "David L. Mills"
> <mills at udel.edu> 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
> per at hedeland.org
More information about the questions
mailing list