From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.ebshome.net (gate.ebshome.net [64.81.67.12]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "gate.ebshome.net", Issuer "gate.ebshome.net" (not verified)) by ozlabs.org (Postfix) with ESMTP id D64866801A for ; Wed, 10 Aug 2005 02:59:59 +1000 (EST) Date: Tue, 9 Aug 2005 09:59:57 -0700 From: Eugene Surovegin To: Rune Torgersen Message-ID: <20050809165957.GE22053@gate.ebshome.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: Cc: linuxppc-embedded@ozlabs.org Subject: Re: Wall clock accuracy List-Id: Linux on Embedded PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Tue, Aug 09, 2005 at 11:57:04AM -0500, Rune Torgersen wrote: > > -----Original Message----- > > From: Eugene Surovegin [mailto:ebs@ebshome.net] > > Sent: Tuesday, August 09, 2005 11:41 > > Hmm, if I'm correct this clock drift (130ppm) should be > > handled easily > > by NTPD without stepping clock but with slewing. This is why NTPD > > exists in the first place, so I don't see any reason to change > > the kernel. > > NTPD probably handles this correct, but I would like the time to be > correct anyways. In our case we might not always have access to a ntpd > server, and our input clock is very accurate to begin with. Well, NTPD doesn't mean you need to have network connectivity, IIRC if you have exact frequency source, you can add it to NTPD and it'll use it to correct drift. -- Eugene