Hi,
Paul and I have been doing some testing of OpenNTPD on various OSes,
and found some interesting deviations. Paul noted that running the
latest OpenNTPD-portable on OmniOS (Solaris derivative) that it would
cycle back and forth between 'clock is now synced' and 'clock is now
unsynced'. So, we put together a short test program to test behavior
of adjtime:
#include <sys/time.h>
#include <errno.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
int main(int argc, char *argv[])
{
struct timeval a, b, c = { 0 };
a.tv_sec = 0;
a.tv_usec = 500000;
if (argc > 1)
a.tv_usec = atoi(argv[1]);
printf("setting adjtime to %lu usec\n", (long)a.tv_usec);
if (adjtime(&a, &b) == -1) {
perror("adjtime");
return 1;
}
do {
sleep(1);
// try putting &c for Solaris in the first arg
if (adjtime(NULL, &b) == -1) {
perror("adjtime");
return 1;
}
printf("%ld usec left\n", b.tv_usec);
} while (b.tv_usec != 0);
return 0;
}
OpenBSD appears to adjust by 5000 usec/sec.
Linux appears to adjust by 500 usec/sec.
Solaris adjust by...well, who knows what amount. But, it is
inconsistent in its ability to eventually hit '0', especially if the
clock frequency adjustment for 'adjfreq/ntpd_adjtime' was ever set to
anything other than '0'. It also doesn't allow specifying a NULL first
argument to adjtime, so a run looks something like this:
setting adjtime to 500000 usec
437963 usec left
375299 usec left
312634 usec left
249343 usec left
186679 usec left
124015 usec left
-339216 usec left
-272516 usec left
-205817 usec left
-139740 usec left
-73041 usec left
-6341 usec left
-3 usec left
-3 usec left
-3 usec left
In a number of machines, it never hits '0' at all, simply gets kind of
close. I was wondering if it made sense to either:
1. add some sort of fudge factor to the clock 'synced' state when
the olddelta simply stabilizes (not sure if there's a good technique
here)?
2. quiet the debug logging for synced/unsynced
3. document as a Solaris bug and move on?
I got the same behavior after running ntp.org's ntpd and openntpd (and
stopping them) and having adjfreq pre-set, so I don't think its a case
of us programming adjfreq/ntp_adjtime incorrectly. It seems this
behavior first showed up since OpenNTPD-portable now calls adjfreq. It
is also possible that if we never call adjfreq that Solaris does
eventually adjust the time all the way. We've tested on a variety of
Solaris 10 / 11 and x86 and Sparc hardware.
- Brent
