Date: Wed, 7 Apr 1999 22:18:51 +0200 (SAT) From: John Hay <jhay@mikom.csir.co.za> To: dillon@apollo.backplane.com (Matthew Dillon) Cc: Don.Lewis@tsc.tdk.com, nsayer@FreeBSD.org, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern kern_time.c Message-ID: <199904072018.WAA11097@zibbi.mikom.csir.co.za> In-Reply-To: <199904071924.MAA05436@apollo.backplane.com> from Matthew Dillon at "Apr 7, 1999 12:24:29 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> :On Apr 7, 9:36am, Nick Sayer wrote: > :} Subject: cvs commit: src/sys/kern kern_time.c > : > :} We still need to decide on an algorithm to clamp positive adjustments. > :} As it stands, it is possible to achieve arbitrary negative adjustments > :} by "wrapping" time around. > : > :Limit positive steps to MIN(1 second, elapsed time since last postive step). > :At worst the clock could be made to run at 2x normal speed. > : > : --- Truck > > That's a pretty good solution. If this is combined with calling > 'ntpdate' on boot to step the time prior to starting xntpd, I think > we wind up with quite a reasonable setup. Once stepped, xntpd isn't > likely to have to do anything major. Besides, in order to be 'safe' > from PC realtime clock chip Y2K issues you pretty much have to step > the time by syncing it to an external source with ntpdate on boot > anyway. > Well if this is just to keep (x)ntpd happy, you can just compile xntpd-3 with the SLEWALWAYS option or run ntpd-4 with the -x option and it shouldn't ever step the time... At least that is what the docs and source says. I haven't tried it myself. John -- John Hay -- John.Hay@mikom.csir.co.za To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199904072018.WAA11097>