NTPD unable to adjust local clock
joerg at britannica.bec.de
Wed Apr 6 12:04:36 PDT 2005
On Wed, Apr 06, 2005 at 11:47:47AM -0700, Matthew Dillon wrote:
> As I said... it's broken. There is NO WAY to correct the clock with
> adjtime(), that's why ntp_adjtime() exists. In the early days real time
> clocks used reasonably high quality crystals and it wasn't a problem.
> Today's PC's use poor quality, non-thermally compensated crystals or
> even don't use crystals at all (they use something based off one of the
> motherboard's frequency multipliers, which are TERRIBLE time keepers).
I would send a box with a timer doing more than 30ms / 60s back immediately.
Oscillating clocks are not a problem (as in: oscillating vs. the referencer
time), the question is how big that difference is. I'm pretty sure now
that the current behaviour is simply a bug in the offset determination code.
I just have to think how to best fix it.
Somewhat related, what do you think about the attached patch? It removes
the limitation of adjtime working only in steps of tickadj (30ms).
RCS file: /home/joerg/wd/repository/dragonflybsd/src/sys/kern/kern_clock.c,v
retrieving revision 1.31
diff -u -r1.31 kern_clock.c
--- kern_clock.c 13 Mar 2005 21:33:47 -0000 1.31
+++ kern_clock.c 6 Apr 2005 18:21:55 -0000
@@ -312,6 +312,8 @@
timedelta -= tickdelta;
+ if (timedelta > 0 && timedelta < tickdelta)
+ tickdelta = timedelta;
RCS file: /home/joerg/wd/repository/dragonflybsd/src/sys/kern/kern_time.c,v
retrieving revision 1.19
diff -u -r1.19 kern_time.c
--- kern_time.c 29 Mar 2005 00:35:55 -0000 1.19
+++ kern_time.c 6 Apr 2005 18:21:55 -0000
@@ -460,8 +460,10 @@
ntickdelta = 10 * tickadj;
ntickdelta = tickadj;
if (ndelta % ntickdelta)
ndelta = ndelta / ntickdelta * ntickdelta;
* To make hardclock()'s job easier, make the per-tick delta negative
More information about the Users