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: [email protected] > [mailto:[email protected]] On > Behalf Of A C > Sent: Tuesday, October 11, 2011 4:12 PM > To: [email protected] > Subject: Re: [ntp:questions] PPS time1 and reported offset > > On 10/11/2011 09:04, unruh wrote: > > On 2011-10-07, A C<[email protected]> 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 > [email protected] > http://lists.ntp.org/listinfo/questions _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
