On Mon, Nov 14, 2005 at 03:55:21PM +0100, the unit calling itself Moritz Grimm wrote:
> >I just installed 3.8 on a Soekris net4801 that's been laying around for > >a while (unused, unpowered). I noticed after install that time was off > >by like 5 months, so I set it to within a few minutes of current > >time/date from the wall clock. > > > >I've been checking the logs, and this is what I'm seeing... this has > >been going on for about 8 hours now. Why is ntpd having to make 60+ > >second adjustments every 3-5 minutes? It would appear the clock on the > >Soekris is really BFU. > [...] > >Nov 14 06:30:10 opie ntpd[4133]: adjusting local clock by -91.931803s > >Nov 14 06:34:22 opie ntpd[4133]: adjusting local clock by -90.983786s > [...] > >Nov 14 08:24:20 opie ntpd[4133]: adjusting local clock by -64.294286s > >Nov 14 08:27:59 opie ntpd[4133]: adjusting local clock by -63.612736s > > OpenNTPd is working as expected. It is using adjtime(2) to skew the > clock, not set it -- in your case, it is slowing it down until it is synced. Hmmm... OK - I read man for adjtime(2), and I appreciate your explanation with skewing vs setting. However, the output says "adjusting local clock by XX s"... that seems pretty straightforward to me. I think the output is just misleading; it should say: "adjusting local clock to reduce error of XXs" If you told someone you were adjusting their clock by 60 seconds, I think most English-speaking people would conclude that you just changed the clock by a value of 60 seconds - not that I am making an incremental adjustment in your clock to reduce the amount of error such that it is less than 60 seconds. Some additional entries from my log show that in fact ntpd did finally reach closure as of 12:57:40 today (yeah!) Nov 14 12:29:50 opie ntpd[4133]: adjusting local clock by -5.494670s Nov 14 12:34:05 opie ntpd[4133]: adjusting local clock by -4.846304s Nov 14 12:37:03 opie ntpd[4133]: adjusting local clock by -3.931653s Nov 14 12:39:18 opie ntpd[4133]: adjusting local clock by -3.201504s Nov 14 12:43:19 opie ntpd[4133]: adjusting local clock by -2.477988s Nov 14 12:46:12 opie ntpd[4133]: adjusting local clock by -1.698618s Nov 14 12:49:53 opie ntpd[4133]: adjusting local clock by -0.904406s Nov 14 12:52:53 opie ntpd[4133]: adjusting local clock by -0.227882s Nov 14 12:57:40 opie ntpd[4133]: adjusting local clock by 0.264980s Nov 14 12:57:40 opie ntpd[14058]: clock is now synced Nov 14 12:59:30 opie ntpd[14058]: peer 66.11.161.129 now invalid Nov 14 13:00:48 opie ntpd[4133]: adjusting local clock by 0.652100s Nov 14 13:05:04 opie ntpd[4133]: adjusting local clock by -0.271403s This is all very cool, but I still think the log messages are misleading. > Run rdate(8) to speed up the syncing process the hard way (the clock > will jump.) Read up on ntpd(8)'s parameter `-s' in case you ever need to > set a clock that is way off. Thanks for that... as it turns out, the wall clock that I referred to when I set the time using 'date' (immediately after the install) was off "real time" by about 120 seconds... ntpd took approximately 12 hours to work this off. This is fine - the log messages just threw me off. Thanks, Jay
