acpi timer problems?

On Mon, 26 Jun 2006 02:07:22 +0000 (UTC), christosastron.com (Christos
Zoulas) wrote:
> 
> Does it do better with i8254?
> 
I haven't run it that way for nearly as long, but the
answer seems to be yes,
it does better:

$ ntpq -c peer
     remote           refid      st t when poll reach  
delay   offset  jitter
============================================================
==================
+csss.cs.sfu.ca  142.58.103.1     3 u    2   64  377  
82.892   33.884  25.477
+24-231-211-108. 130.126.24.53    3 u   17   64  277  
66.083   39.354  24.542
*216.106.191.180 192.5.41.41      2 u   12   64  377  
45.019   71.339  30.773
+kamaji.efball.c 69.25.96.12      2 u   15   64  277  
95.218   50.402  20.514

(I restarted ntpd after switching timers, to give it a clean
history.)

		--Steven M. Bellovin, http://www.cs.columbi
a.edu/~smb

On Sun, Jun 25, 2006 at 11:30:14PM -0400, Steven M. Bellovin
wrote:
> On Mon, 26 Jun 2006 02:07:22 +0000 (UTC), christosastron.com (Christos
> Zoulas) wrote:
> > 
> > Does it do better with i8254?
> > 
> I haven't run it that way for nearly as long, but the
answer seems to be yes,
> it does better.

I presume this is what you were using as a timecounter until
recently,
given TSC vs speedstep?

What you will probably find is that the ntp drift value
needs to be
entirely different for each counter; each source has its own
frequency
error and bias.  When you switch counters while using a
drift value
calculated with different counter source, I've noticed it
can take up
to several days to stabilise and re-adjust the drift
accordingly
(maybe less, I wasn't checking so often after the first
hour or two),
and in the meantime you get wider offsets because ntpd is
compensating
for the incorrect drift.

So if you switched back to the same counter you were using
previously
soon enough that the new one hadn't altered drift much, it
doesn't
surprise me that ntpd does better quickly after restart.

I don't know whether zapping ntp.drift (ie, starting with 0
or
'undefined') will help ntp close in on a correct new drift
value any
sooner than starting with a wrong value.

--
Dan.

without having looked at code (always EFATAL) you would hope
that a
zero driftfile was a special case, and did some kind of
'average over
<n> x initial samples' interpolation to get an
initial approximation at
least close to the right side of the asymptote..

surely dave mills would have DTRT when initializing from
zero, as
distinct from cached state?

Ie, if the driftfile is predictably wrong, because you
changed
timesource, I can't see how its ever right to keep it..

-G

On Mon, 26 Jun 2006 13:44:45 +1000, Daniel Carosone
<dangeek.com.au>
wrote:

> On Sun, Jun 25, 2006 at 11:30:14PM -0400, Steven M.
Bellovin wrote:
> > On Mon, 26 Jun 2006 02:07:22 +0000 (UTC),
christosastron.com (Christos
> > Zoulas) wrote:
> > > 
> > > Does it do better with i8254?
> > > 
> > I haven't run it that way for nearly as long, but
the answer seems to be yes,
> > it does better.
> 
> I presume this is what you were using as a timecounter
until recently,
> given TSC vs speedstep?
> 
> What you will probably find is that the ntp drift value
needs to be
> entirely different for each counter; each source has
its own frequency
> error and bias.  When you switch counters while using a
drift value
> calculated with different counter source, I've noticed
it can take up
> to several days to stabilise and re-adjust the drift
accordingly
> (maybe less, I wasn't checking so often after the
first hour or two),
> and in the meantime you get wider offsets because ntpd
is compensating
> for the incorrect drift.
> 
> So if you switched back to the same counter you were
using previously
> soon enough that the new one hadn't altered drift
much, it doesn't
> surprise me that ntpd does better quickly after
restart.
> 
> I don't know whether zapping ntp.drift (ie, starting
with 0 or
> 'undefined') will help ntp close in on a correct new
drift value any
> sooner than starting with a wrong value.
> 
OK -- ntp.drift zapped; timer switched back to ACPI_PM_TMR;
ntpd
restarted.  The previous kernel was indeed pretimecounter.


		--Steven M. Bellovin, http://www.cs.columbi
a.edu/~smb

On Mon, 26 Jun 2006 13:51:50 +1000, George Michaelson
<ggmapnic.net>
wrote:

> 
> without having looked at code (always EFATAL) you would
hope that a
> zero driftfile was a special case, and did some kind of
'average over
> <n> x initial samples' interpolation to get an
initial approximation at
> least close to the right side of the asymptote..
> 
> surely dave mills would have DTRT when initializing
from zero, as
> distinct from cached state?
> 
> Ie, if the driftfile is predictably wrong, because you
changed
> timesource, I can't see how its ever right to keep
it..
> 
I think that that's Dan's point -- /var/db/ntp.drift is
for state between
boots.  It's supposed to measure the difference over time
between your
machine's clock and reality, and you rarely switch clocks. 
It isn't
supposed to compensate for the errors in your ntp peers; ntp
assumes that
there's One True Time, and doesn't use averaging, for
example.


		--Steven M. Bellovin, http://www.cs.columbi
a.edu/~smb

 
> I think that that's Dan's point -- /var/db/ntp.drift
is for state
> between boots.  It's supposed to measure the
difference over time
> between your machine's clock and reality, and you
rarely switch
> clocks.  It isn't supposed to compensate for the
errors in your ntp
> peers; ntp assumes that there's One True Time, and
doesn't use
> averaging, for example.
> 
> 
> 		--Steven M. Bellovin, http://www.cs.columbi
a.edu/~smb

right. so if you switch internal clock models, the ntp.drift
is
inherently invalid, and the right thing (tm) is to junk it.

-George

On Mon, 26 Jun 2006 14:23:53 +1000, George Michaelson
<ggmapnic.net>
wrote:

>  
> > I think that that's Dan's point --
/var/db/ntp.drift is for state
> > between boots.  It's supposed to measure the
difference over time
> > between your machine's clock and reality, and you
rarely switch
> > clocks.  It isn't supposed to compensate for the
errors in your ntp
> > peers; ntp assumes that there's One True Time,
and doesn't use
> > averaging, for example.
> > 
> > 
> > 		--Steven M. Bellovin, http://www.cs.columbi
a.edu/~smb
> 
> right. so if you switch internal clock models, the
ntp.drift is
> inherently invalid, and the right thing (tm) is to junk
it.
> 
Yes; that's what I did last night.  This morning's offsets
look much
better, though I'll see what happens during the day.

		--Steven M. Bellovin, http://www.cs.columbi
a.edu/~smb

On Mon, 26 Jun 2006 08:08:03 -0400, "Steven M.
Bellovin"
<smbcs.columbia.edu> wrote:

> On Mon, 26 Jun 2006 14:23:53 +1000, George Michaelson
<ggmapnic.net>
> wrote:
> 
> >  
> > > I think that that's Dan's point --
/var/db/ntp.drift is for state
> > > between boots.  It's supposed to measure the
difference over time
> > > between your machine's clock and reality,
and you rarely switch
> > > clocks.  It isn't supposed to compensate for
the errors in your ntp
> > > peers; ntp assumes that there's One True
Time, and doesn't use
> > > averaging, for example.
> > > 
> > > 
> > > 		--Steven M. Bellovin, http://www.cs.columbi
a.edu/~smb
> > 
> > right. so if you switch internal clock models, the
ntp.drift is
> > inherently invalid, and the right thing (tm) is to
junk it.
> > 
> Yes; that's what I did last night.  This morning's
offsets look much
> better, though I'll see what happens during the day.
> 
After several days, it's keeping time very well, probably
better than it
was before.

Again -- after switching timer type, remove your
/var/db/ntp.drift file.

		--Steven M. Bellovin, http://www.cs.columbi
a.edu/~smb