[ntp:questions] Re: ntpd transmit timestamp precision

David L. Mills mills at udel.edu
Fri Feb 17 21:54:35 UTC 2006


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.


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