I’ve got a machine with a really bad clock. When I run NTP on it, the freq goes straight to 500.0 (over a period of a few days) and stays there, while the offset grows and grows. I recently switched this machine from Debian Linux to FreeBSD (wanting to learn more about FreeBSD). Under Linux, I used adjtimex to modify the TICK value and (once I had converged on the right value) NTP was able to stabilize the clock. Is there an equivalent hack for FreeBSD? Thanks! Rick

On 2015-02-11 18:35, Rick Thomas wrote: > > I’ve got a machine with a really bad clock. > When I run NTP on it, the freq goes straight to 500.0 (over a period of a few days) > and stays there, while the offset grows and grows. > I recently switched this machine from Debian Linux to FreeBSD >(wanting to learn more about FreeBSD). > Under Linux, I used adjtimex to modify the TICK value and (once I had converged on > the right value) NTP was able to stabilize the clock. > Is there an equivalent hack for FreeBSD? See http://lists.freebsd.org/pipermail/freebsd-stable/2010-February/055369.html and rest of thread. First check your BIOS and OS have spread spectrum frequency changes and sleep states disabled, as those will make all clock sources appear unreliable. Then check your clock sources as shown earlier in the quoted thread and see if changing the clock source gives lower frequency drift. If your frequency drift is still excessive, try doing the calculation as in the quoted post and change your clock source frequency to compensate. Stop ntpd and rm ntp.drift before applying any clock source change. Let ntpd run for a few hours; use ntpq -c rv to check frequency for convergence, and offset for convergence towards zero; once those values start changing in the opposite direction, ntpd is disciplining the clock, and the values should start oscillating around its best estimates. -- Take care. Thanks, Brian Inglis