[ntp:questions] PPS time1 and reported offset

Charles Elliott elliott.ch at verizon.net
Wed Oct 12 13:57:56 UTC 2011


Using version 4.2.7p98-win-x86 of NTPD downloaded from 
Dave Hart's Web site at http://www.davehart.net/ntp/win/x86/ time1 is now
time2.
Just change time1 to time2 in the config file and NTPD works as expected.
In addition, this fudge line no longer accepts comments; any # on the line
causes NTPD to choke and not activate the NMEA clock.  I don't know if this
change applies to the Linux version or not, nor do I know if this is an
answer to your problem

Charles Elliott


> -----Original Message-----
> From: questions-bounces+elliott.ch=verizon.net at lists.ntp.org
> [mailto:questions-bounces+elliott.ch=verizon.net at lists.ntp.org] On
> Behalf Of A C
> Sent: Tuesday, October 11, 2011 4:12 PM
> To: questions at lists.ntp.org
> Subject: Re: [ntp:questions] PPS time1 and reported offset
> 
> On 10/11/2011 09:04, unruh wrote:
> > On 2011-10-07, A C<agcarver+ntp at acarver.net>  wrote:
> >> I'm trying something out with my local ntpd and its PPS feed from
> the GPS.
> >>
> >> Let us assume that the pulse from the GPS receiver is off from the
> >> master UTC clock tick by about 3 ms due to a variety of delays in
> the
> >> overall system starting from the satellite and working its way down
> to
> >> ntpd.  (No arguments about how I get to that number, we're just
> assuming
> >> this is the case).
> >
> > Well, in that case throw out your system. Something is very very
> badly
> > wrong. And how in the world would you know that to be the case
> anyway?
> > What do you have that is a better clock than the GPS?
> > How are you  receiving the PPS feed? The kernel PPS? GPSD?
> shmpps?....
> 
> I did say no arguments.  Just make the assumption and move on.  A GPS
> is
> a very good clock but it is not immune to delay from the time the
> signals leave the satellites to the time the signal arrives at ntpd.
> 
> No more arguments, I just want to find the answer to the question below
> about ntpd's behavior with an offset applied by time1.
> 
> >> If a server (or the GPS NMEA data) is off from the master clock by
> some
> >> amount, you correct for the delay with time1 and, according to ntpq
> -p,
> >> the offsets eventually trend towards zero.  However, that's not what
> I
> >> see if I set time1 to 0.003 on the PPS input. What I see there is a
> >> constant 3.000 reading in the offset column (plus or minus a bit of
> >> drift/jitter).   It never seems to wind down to zero like a server
> or
> >> the NMEA reference clock as the clock is disciplined.
> >>
> >> Is this normal behavior for the PPS input or should I expect what I
> >> normally see on other servers?  I would have expected that the
> offset is
> >> some amount but eventually comes down to zero or near zero as the
> clock
> >> is disciplined over the course of ntpd's operation.
> _______________________________________________
> questions mailing list
> questions at lists.ntp.org
> http://lists.ntp.org/listinfo/questions



More information about the questions mailing list