gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-dev] Disturbing numbers


From: Andy Walls
Subject: Re: [gpsd-dev] Disturbing numbers
Date: Sun, 03 Nov 2013 14:38:19 -0500


On Sun, 2013-11-03 at 14:29 -0500, Eric S. Raymond wrote:
> Andy Walls <address@hidden>:
> > > I do notice a curious thing, though. While I've been composing this reply 
> > > my PPS offset has crept up from 2 to 13 mSec, and seems to be steadily 
> > > rising.  What does this indicate?
> > 
> > If just (re)started without a drift file, ntpd has a start up
> > calibration period on the order of minutes while it ponders things.
> > 
> > My guess is that your system clock is drifting with respect to UTC and
> > the PPS while ntpd is calibrating and letting things free-run.
> > 
> > If this is the case, ntpd could take up to 15 minutes for ntpd to kick
> > in, step the clock, and start adjusting the frequency and offset of your
> > system clock. 
> 
> This is exactly the sort of thing that needs to go in the Time Service HOWTO!
> 
> The 15 minutes fits pretty exactly.  A couple of minutes after I sent my 
> reply the offset started dropping again, bottomed out at about 2mSec and
> is slowly rising again.
> 
> Is a long-period sawtooth what I should expect to see?

Sounds reasonable for startup.  I wouldn't expect it at steady/stable
state.

ntpd prefers to slew clocks into alignment.

system clock frequency will change, and ntpd will have to adjust it, a
bit until your computer is thermally stable.

Do keep in mind, that compared to a decent PPS, it is the ntpd
disciplined system clock which is drifting.


> Yay, visualization tools.

Wait til you give ntpd a local PPS using the ntpd ATOM clock driver.
You'll see ntpd lock the system clock to the PPS after start-up
calibration, and the clock will vary very little afterward.

Regards,
Andy




reply via email to

[Prev in Thread] Current Thread [Next in Thread]