RE: Wall clock accuracy

3 messages, 2 authors, 2005-08-09 · open the first message on its own page

RE: Wall clock accuracy

From: Rune Torgersen <hidden>
Date: 2005-08-09 16:57:06

-----Original Message-----
From: Eugene Surovegin [mailto:ebs@ebshome.net]=20
Sent: Tuesday, August 09, 2005 11:41
Hmm, if I'm correct this clock drift (130ppm) should be=20
handled easily=20
by NTPD without stepping clock but with slewing. This is why NTPD=20
exists in the first place, so I don't see any reason to change=20
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.

Re: Wall clock accuracy

From: Eugene Surovegin <hidden>
Date: 2005-08-09 16:59:59

On Tue, Aug 09, 2005 at 11:57:04AM -0500, Rune Torgersen wrote:
quoted
-----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

Re: Wall clock accuracy

From: Eugene Surovegin <hidden>
Date: 2005-08-09 17:02:55

On Tue, Aug 09, 2005 at 09:59:57AM -0700, Eugene Surovegin wrote:
On Tue, Aug 09, 2005 at 11:57:04AM -0500, Rune Torgersen wrote:
quoted
quoted
-----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.
To rephrase this - Linux kernel already has infrastructure for 
precision time keeping, just use it (even without NTPD) and don't add 
any CPU-specific hacks :).

-- 
Eugene
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help