From owner-cvs-etc Sun Apr 27 06:48:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id GAA12246 for cvs-etc-outgoing; Sun, 27 Apr 1997 06:48:07 -0700 (PDT) Received: from spinner.DIALix.COM (root@spinner.dialix.com [192.203.228.67]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA12223; Sun, 27 Apr 1997 06:47:49 -0700 (PDT) Received: from spinner.DIALix.COM (peter@localhost.DIALix.oz.au [127.0.0.1]) by spinner.DIALix.COM with ESMTP id VAA07550; Sun, 27 Apr 1997 21:47:35 +0800 (WST) Message-Id: <199704271347.VAA07550@spinner.DIALix.COM> X-Mailer: exmh version 2.0gamma 1/27/96 To: Bruce Evans cc: cvs-all@FreeBSD.org, CVS-committers@FreeBSD.org, cvs-etc@FreeBSD.org, jkh@FreeBSD.org Subject: Re: cvs commit: src/etc rc rc.network In-reply-to: Your message of "Sun, 27 Apr 1997 22:30:47 +1000." <199704271230.WAA07923@godzilla.zeta.org.au> Date: Sun, 27 Apr 1997 21:47:34 +0800 From: Peter Wemm Sender: owner-cvs-etc@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Bruce Evans wrote: > > Branch: etc RELENG_2_2 > > Modified: etc rc rc.network > > Log: > > tickadj is useful even if ntpdate isn't selected (clock drift isn't > > isolated to network time users) so make it a fully independant knob. > > Suggested-By: Richard Crook > > tickadj is not useful: > > BUGS > Fiddling with kernel variables at run time as a part of > ordinary operations is a hideous practice which is only > necessary to make up for deficiencies in the implementa- > tion of adjtime(8) in many kernels and/or brokenness of > ^ bug, should be 2 > the system clock in some vendors' kernels. It would be > much better if the kernels were fixed and the tickadj pro- > gram went away. > > Since FreeBSD's adjtime(2) doesn't have these deficiencies, there is no > need for tickadj. > > In FreeBSD-2.2, you can also fine tune the system clock using `sysctl > -w machdep.i8254_freq=whatever'. This sets the nominal frequency to > match the actual frequency (the actual frequency can be inferred from > the drift). It has much the same effect as using tickadj to modify > `tick' except it is free from certain undesirable side effects of > modifying `tick'. Resolution is limited to +-0.5 usec per tick for > the same reasons as it is limited for the tickadj method (this will > be fixed someday), so you still need to use adjtime(8) or xntpd(8) > for fine control. adjtime(8) isn't standard in FreeBSD. I recommend > using xntpd with the kernel PLL even on systems not connected to networks. Well, I wish somebody would explain why I see this sort of thing on every single FreeBSD machine I work with, and how to stop it. Is the default tickadj -Aq causing this perhaps? Apr 27 10:39:07 pasteur xntpd[171]: time reset (step) -0.418709 s Apr 27 10:45:01 pasteur xntpd[171]: time reset (step) 0.561284 s Apr 27 12:33:07 pasteur xntpd[171]: Previous time adjustment didn't complete Apr 27 16:32:48 pasteur xntpd[171]: time reset (step) -0.223744 s Apr 27 16:38:15 pasteur xntpd[171]: time reset (step) 0.385576 s Apr 27 18:05:41 pasteur xntpd[171]: time reset (step) -0.614054 s Apr 27 18:11:39 pasteur xntpd[171]: time reset (step) 0.756201 s Apr 27 21:45:56 pasteur xntpd[171]: time reset (step) -0.304020 s Apr 27 22:10:28 pasteur xntpd[171]: time reset (step) 0.255533 s It seems to go through wild oscillations quite regularly. What worrys me is that xntpd seems to call adjtime() very frequently, about every second or so.. Does it have it's own PLL inside xntpd? Does having a PLL driving a PLL work? Other details: remote local st poll reach delay offset disp ======================================================================= *tictoc.dap.CSIR 203.12.3.8 1 256 377 0.05458 -0.061465 0.03783 % cat /etc/ntp.drift 24.454 0 (All machines have both of the CLK_USE_xxx_CALIBRATION options set) % sysctl machdep | grep freq machdep.i8254_freq: 1193174 machdep.i586_freq: 119751287 # tickadj tick = 10000 us, tickadj = 5 us calculated hz = 100.00 Hz recommended value of tickadj = 5 us > In-FreeBSD-2.2, you can also use the option CLK_USE_I8254_CALIBRATION > to attempt to initialize the nominal i8254 frequency better, or you > can boot with -v and note the frequency and set it later using sysctl. > The frequency is calibrated relative to the RTC which may be more > accurate. > > Bruce Cheers, -Peter