> Date: Wed, 23 Oct 2019 11:43:25 +0200 > From: Otto Moerbeek <[email protected]> > > On Wed, Oct 23, 2019 at 11:17:02AM +0200, Paul de Weerd wrote: > > > Hi Otto, > > > > On Wed, Oct 23, 2019 at 10:58:24AM +0200, Otto Moerbeek wrote: > > | I could * this has to do with the logging changes. Previously, debug > > | messages could disappear because of wrong logging setup. In non -v > > | mode, only big adjustments are logged. Sadly you stripped those > > | numbers away so i cannot tell how big the adjustments are. > > > > The recent adjustments that happen during runtime are bigger than what > > was logged previously at boot: > > > > 2019-06-07T13:15:53.341Z despair ntpd[4423]: adjusting local clock by > > -0.068174s > > 2019-09-04T05:38:00.448Z despair ntpd[94384]: adjusting local clock by > > 0.205606s > > 2019-09-25T04:30:45.225Z despair ntpd[43359]: adjusting local clock by > > 0.352666s > > 2019-09-30T20:13:34.739Z despair ntpd[57871]: adjusting local clock by > > 1.172165s > > 2019-10-02T02:55:02.851Z despair ntpd[57871]: adjusting local clock by > > 2.788555s > > 2019-10-02T03:21:39.721Z despair ntpd[57871]: adjusting local clock by > > -0.043674s > > 2019-10-02T06:23:22.228Z despair ntpd[57871]: adjusting local clock by > > -0.343597s > > 2019-10-02T06:51:22.766Z despair ntpd[57871]: adjusting local clock by > > -0.112257s > > 2019-10-02T07:42:06.567Z despair ntpd[57871]: adjusting local clock by > > -0.108361s > > 2019-10-03T02:18:06.172Z despair ntpd[57871]: adjusting local clock by > > 2.792710s > > 2019-10-03T02:46:26.658Z despair ntpd[57871]: adjusting local clock by > > -0.056351s > > 2019-10-03T03:37:45.273Z despair ntpd[57871]: adjusting local clock by > > -0.135864s > > 2019-10-03T04:49:06.489Z despair ntpd[57871]: adjusting local clock by > > -0.092314s > > 2019-10-03T04:59:25.046Z despair ntpd[57871]: adjusting local clock by > > -0.119596s > > 2019-10-04T03:14:01.960Z despair ntpd[57871]: adjusting local clock by > > 2.789228s > > > > Below is a bit more history (from early January this year). > > > > The wildly varying clock frequency is the reason I'm suspecting > > hardware failure... > > Yeah pretty wild. This is a machine that is permanently on?
This may be a consequence of the timecounter choice. Did the output of kern.timecounter change on this machine? What is the output of sysctl kern.timecounter in this state?
