> Drop local driver as that is intended for systems with an external > clock source providing an accurate disciplined system clock.
That doesn't quite make sense to me. (To be sure we are talking about the same thing, I assume you are referring to my "server 127.127.1.0".) My use case appears to align with the documented [1] examples. I /do/ want it to be the "designated time server to act as a primary server to provide synchronization to other clients on the network" [paragraph one], and "the clock of last resort when all other normal synchronization sources have gone away" [paragraph two] and "when an external discipline source [like a modem] is available" [paragraph three]. Well, not a modem, but an external NTP source is available at least a couple of times a day! Of course, perhaps I'm not understanding correctly, so do please tell me again if you think including the local clock is bad. > Set up your NMEA clock as prefer peer, and change fudge time to > centre offset to PPS around zero. OK - that sounds sensible. The fudge time in my ntp.conf (fudge 127.127.28.0 time1 0.183106) was indeed set in that way. From memory, I configured ntpd to watch the NMEA but not to synchronise, waited for everything to settle and collected offset readings over a day or so. The fudge factor is a result of averaging out those samples. At the time, I was pretty happy with the result and I'm not sure I could do better with that driver (driver28). > If your ref clock generates NMEA sentences, try using the NMEA > driver, which tries to compensate for sentence timing, instead of > gpsd SHM. Ah, ntpd - it's like a game of whack-a-mole - fix one issue, create another in doing so. I'm using gpsd because I want to use the NMEA sentences in other places (hence the use of gpsd). Now of course, I could duplicate the serial port - as in create a "virtual serial port" so that both gpsd and the NMEA driver could get the same serial data. That, however, is another thing to break and add timing errors. I also recall some issues where I tried using the NMEA driver (driver20) but it ended up snarfing the PPS signal. Or refusing to play nicely with driver22. Or something like that. I've always found ntpd to be a little on the touchy side. Unfortunately I can't remember the exact details on why I ended up with my current setup. > If PPS still does not work reliably, remove the PPS driver and see > if the NMEA driver will run with user mode PPS provided by the > driver. The PPS /was/ working very reliably... until my prefer peer disappeared. The ntpq output probably isn't at all representative of everything "working"... but it is rather illustrative of why I'm hoping to improve my configuration. On the balance, I think I'd prefer to keep the NMEA and the PPS as separate time sources - if only so I can monitor them separately. > Let each configuration run for at least six hours and watch > ntpq -p -c rv -c cv for precision <= -20, stabilizing frequency and > offset, loopstats drift and offset, and ref clock peerstats offset. OK, I can do that. Thanks for your detailed input. Let me know what you think about the local clock, if you significantly disagree with my fudge factor on driver28 and if you think the NMEA driver (20) is significantly better than the SHM driver (28) for my particular case. [1] http://doc.ntp.org/4.1.1/driver1.htm -- Paul. _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
