> > Easy with the 28 refclock. Not sure on the 20. DO you even see the > coarse time with ntpq -p?
I don’t know enough to answer regarding “coarse time”. Here’s my output (FreeBSD-10.3-RELEASE): [2.3-RELEASE][ad...@burns.springfield.com]/root: ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== oGPS_NMEA(0) .GPS. 0 l 6 16 377 0.000 -0.002 0.003 *tock.usshc.com .GPS. 1 u 26 64 377 32.138 4.606 0.901 +clock.isc.org .GPS. 1 u 21 64 377 70.356 -0.027 0.995 -tick.apple.com .GPS. 1 u 47 64 227 147.752 40.539 163.016 -ntp.wdc1.us.lea 199.102.46.72 2 u 47 64 377 49.799 20.090 3.552 -leeloo.scurvyne 173.162.192.156 2 u 47 64 377 142.869 16.063 34.157 -2001:19f0:8000: 132.163.4.101 2 u 2 64 377 65.329 -7.336 0.499 +67.212.117.78 128.138.141.172 2 u 46 64 377 38.889 -4.778 0.341 >> Regarding 28 ref clock, that is SHM? Why that rather than NMEA (20)? > > gpsd handles a lot more GPS types than #20. So let gpsd handle the GPS. > gpsd passes the time it determines to ntpd using the SHM (shmctl) > interface. So the type 28 (SHM) is coming from gpsd on the same box? I still like KISS (no need for other GPS type info)... > The long term goal is to kill off #20 as no need to maintain 2 NMEA > parsers. Understood. I still like KISS... > time1 adjusts the PPS derived time, time2 adjusts the NMEA derived time. So for type 20 (NMEA local) & PPS, time2 would be the correct place to put the fudge factor (assuming time1 (PPS) is dead nuts). >> What’s a good way to “tune” my NTP config? > > Compare it to another ntpd server and see which has the least jitter/wander. Got it. >> What’s a good way to monitor my NTP performance? > > I stare at the results of: > > root@pi2:~# watch ntpq -p > > Watch how you local refclock(s) compare to some others. Got it.
_______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel