Mark Davies wrote:
> We had a bunch of machines running current from about 15 months ago 
> and keeping their clocks synchronised with ntp (broadcastclient) and 
> everything was fine - clocks stayed in sync (to within a second or 
> two, probably much finer).
>
> Now these machines have been updated to 4.99.9 (just before newlock 
> was merged) and we are finding it very difficult to keep the clocks 
> in line. eg:
>
> Apr  2 14:07:20 city-art ntpd[925]: time reset -0.291643 s
> Apr  2 14:52:33 city-art ntpd[925]: time reset -0.319601 s
> Apr  2 15:26:45 city-art ntpd[925]: time reset -0.408042 s
> Apr  2 16:04:25 city-art ntpd[925]: time reset -123.117997 s
> Apr  2 16:25:49 city-art ntpd[925]: time reset -15.183592 s
> Apr  2 16:51:30 city-art ntpd[925]: time reset -0.438262 s
> Apr  2 17:07:29 city-art ntpd[925]: time reset -0.448683 s
> Apr  2 23:01:53 city-art ntpd[925]: time reset -0.662605 s
> Apr  2 23:17:04 city-art ntpd[925]: time reset -0.690639 s
> Apr  3 09:35:17 city-art ntpd[925]: time reset -0.657632 s
> Apr  3 09:57:48 city-art ntpd[925]: time reset -0.498326 s
> Apr  3 10:29:54 city-art ntpd[925]: time reset -0.507614 s
> Apr  3 10:45:00 city-art ntpd[925]: time reset -0.340800 s
> Apr  3 11:00:05 city-art ntpd[925]: time reset -0.351110 s
> Apr  3 11:22:30 city-art ntpd[925]: time reset -0.800788 s
> Apr  3 11:42:53 city-art ntpd[925]: time reset -0.263814 s
> Apr  3 12:06:29 city-art ntpd[925]: time reset -0.674662 s
> Apr  3 12:22:31 city-art ntpd[925]: time reset -1.823789 s
> Apr  3 12:46:05 city-art ntpd[925]: time reset -0.563047 s
> Apr  3 13:07:39 city-art ntpd[925]: time reset -0.354673 s
> Apr  3 13:22:52 city-art ntpd[925]: time reset -0.261196 s
> Apr  3 13:42:10 city-art ntpd[925]: time reset -0.530076 s
> Apr  3 14:23:43 city-art ntpd[925]: time reset -0.674130 s
> Apr  3 14:54:40 city-art ntpd[925]: time reset -0.804130 s
> Apr  3 15:09:41 city-art ntpd[925]: time reset -0.407496 s
> Apr  3 15:30:28 city-art ntpd[925]: time reset -0.354883 s
> Apr  3 16:11:17 city-art ntpd[925]: time reset -0.258959 s
> Apr  3 16:46:43 city-art ntpd[925]: time reset -6.695743 s
> Apr  3 17:27:17 city-art ntpd[925]: time reset -35.567960 s
> Apr  3 17:42:27 city-art ntpd[925]: time reset -0.161909 s
> Apr  4 11:09:29 city-art ntpd[925]: time reset +6.110545 s
>
> Including every few days getting a machine thats clock has skewed so 
> far that Kerberos authentication stops working.  The gap in the above 
> log between Apr 3 and Apr 4 included a period when the clock was 
> running 1 hour fast.  What gives?
>
> cheers
> mark
>   
hi,

Short answer is to try a different timecounter.
"sysctl kern.timecounter.choice" to list the choices,
"sysctl -w kern.timecounter.hardware=i8254" (for example) to choose a 
timecounter.
And don't forget to put the one that works in /etc/sysctl.conf

-Tobias