From owner-cvs-all Wed Apr 7 12:26:37 1999 Delivered-To: cvs-all@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 51FA714D2C; Wed, 7 Apr 1999 12:26:35 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id MAA05436; Wed, 7 Apr 1999 12:24:29 -0700 (PDT) (envelope-from dillon) Date: Wed, 7 Apr 1999 12:24:29 -0700 (PDT) From: Matthew Dillon Message-Id: <199904071924.MAA05436@apollo.backplane.com> To: Don Lewis Cc: Nick Sayer , cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/kern kern_time.c References: <199904071917.MAA16146@salsa.gv.tsc.tdk.com> Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk :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. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message