On Fri, Nov 5, 2010 at 20:43 UTC, David L. Mills <mi...@udel.edu> wrote: > The test I did was to run two tests using initial offsets of +90 ms and -90 > s. The tests use ntptime -f 500 or -f -500 for three minutes in order to > change the offset to about +-90 ms, then start ntpd normally. The frequency > file was present and very near the expected hardware frequency. My results > were far different than yours; offset converges to within 0.5 ms and > frequency surge less than 1 PPM. We need to explain why the results are so > far different.
Try it without the drift file and with -100ms if your natural drift is a positive number, or +100ms if your drift is negative. So far my tests of ~100ms initial offset without removing the drift file have not been particularly spectacular, though the offset hasn't been converging to sub-ms in 5 minutes, it's mostly eliminated. Regarding slew limits being different on Solaris compared to FreeBSD and Linux, what I observed on OpenSolaris was slewing up to 63000 PPM using adjtime(). That is, its adjtime() behaved just like FreeBSD and Linux, except with an internal limit on the slew rate of 63000 PPM for OpenSolaris vs 500 PPM for the others. You can try it yourself by running the following program as root with ntpd stopped: #include <stdio.h> #include <sys/time.h> #include <unistd.h> int main() { struct timeval tv, otv; tv.tv_sec = 0; tv.tv_usec = 100000; while (1) { if (adjtime(&tv, &otv)) { printf("fail\n"); return 1; } printf("%ld\n", tv.tv_usec - otv.tv_usec); sleep(1); } return 0; } Miroslav provided the program. I don't have root access to any Solaris 10 systems or I'd try it myself. OpenSolaris output of the above: SunOS psp-os1 5.11 snv_111b i86pc i386 i86pc Solaris h...@psp-os1> sudo sh -c 'svcadm disable ntp ; ./adjtime_rate' 100001 62544 63170 63170 63170 63170 63170 63170 ^C h...@psp-os1> So it appears OpenSolaris no longer has a simple -500, 0, 500 PPM slew transmission, but is more like continuously variable up to 63000 PPM. FWIW, Windows slew is also continuously variable, with no limit that I've reached. I once accidentally had ntpd adjust the clock so it was moving at a few microseconds per tick, vs. nominal 15.625 msec. Cheers, Dave Hart _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions