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
