Udo van den Heuvel via devel writes: > Garmin gps18x on the serial port with USB power. > With just $GPGGA and $GPRMC enabled, so where did it find that weird date?
If you had the clockstats file enabled, you would be able to see what message ntpd received at that point. Since you have RMC enabled, I guess that you got an RMC message into ntpd before it aquired a fix and if you didn't configure anything else, I guess it starts with whatever date the firmware was built. I think your GPS is supposed to store the last known position and time in Flash so this normally should not happen, but either that function isn't enabled or it decided that the information was unusable and did a full cold start. Since that firmware buils certainly was before the recorded build date of ntpd, it (unhelpfully in this case) decides it should pivot that date forward on the assumption you are suffering from GPS rollover issues (no it shouldn't do that unless configured, but that's how the implementation currently works). >> Things should be setup such that servers from the network sanity check your >> GPS clock. What's in your ntp.conf? > > refclock nmea unit 0 mode 7 flag3 1 flag2 0 flag1 0 time1 0.00000006 time2 > 0.260 baud 4800 > refclock pps unit 0 flag2 0 This is a wierd config. You disable PPS processing on the NMEA, then enable kernel PPS discipline and also configure a PPS refclock? You should drop the PPS and enable PPS processing in NMEA instead, IMHO. Set up an udev rule to intialize the GPS correctly (preferrably with just the RMC message) and link the serial and PPS to /dev/gps0 and /dev/gpspps0. The Garmin has the RMI message that allows you to set the expected time and date, so using that during the device initialization to set it up with the current syste time & date should alleviate the problem with it starting up with the firmware build date and warping you into the future. Now, to prevent that from happening again: there are actually two systemd targets that deal with setting up the system time. You will want to use time-set.target to bring up the system time to a known good state and then time-sync.target to keep it there, which you ccan take advantage of by using two different configs for ntpd. The first one potentially steps the system clock, so you should not let any uncontrolled GPS time reach ntpd (I can generally rely on there being enough NTP servers on my local network to converge to the correct time) and then just exits. The second one then never needs to step the time since you start out very close, so you can configure the GPS there. If the GPS freaks out it will be marked as a falseticker and falls back to your network instead of warping system time and if ntpd itself freaks out it will be restarted. ntpsec-steptime.service --8<---------------cut here---------------start------------->8--- [Unit] Description=Network Time Service Documentation=man:ntpd(8) Wants=network.target ConditionCapability=CAP_SYS_TIME After=network.target nss-lookup.target Before=time-set.target Conflicts=systemd-timesyncd.service ntpd.service chrony.service ntp-steptime.service [Service] Type=oneshot PrivateTmp=true ExecStart=/usr/sbin/ntpd -q -g -N -u ntp:ntp -c /etc/ntp-step.conf TimeoutStartSec=60 RemainAfterExit=yes StandardOutput=null Restart=no [Install] WantedBy=time-set.target --8<---------------cut here---------------end--------------->8--- ntpsec-ntpd.service --8<---------------cut here---------------start------------->8--- [Unit] Description=Network Time Service Documentation=man:ntpd(8) Wants=network.target time-set.target ConditionCapability=CAP_SYS_TIME After=time-set.target network.target nss-lookup.target Before=time-sync.target Conflicts=systemd-timesyncd.service ntpd.service chrony.service [Service] Type=forking PIDFile=/run/ntp/ntpd.pid PrivateTmp=true ExecStart=/usr/sbin/ntpd -p /run/ntp/ntpd.pid -N -u ntp:ntp Restart=on-failure [Install] WantedBy=multi-user.target --8<---------------cut here---------------end--------------->8--- ntpsec-wait.service --8<---------------cut here---------------start------------->8--- [Unit] Description=Wait for ntpsec-ntpd to synchronize system clock Documentation=man:ntpwait(8) Requisite=ntpsec-ntpd.service Before=time-sync.target After=ntpsec-ntpd.service Conflicts=systemd-timesyncd.service ntp-wait.service ntpd.service chrony-wait.service chrony.service ConditionVirtualization=!container ConditionCapability=CAP_SYS_TIME Wants=time-sync.target [Service] Type=oneshot ExecStart=/usr/bin/ntpwait -v -s 1 -n 300 RemainAfterExit=yes StandardOutput=journal+console [Install] WantedBy=time-sync.target --8<---------------cut here---------------end--------------->8--- If you've set it up correctly these should have registered as follows: /etc/systemd/system/multi-user.target.wants/ntpsec-wait.service /etc/systemd/system/multi-user.target.wants/ntpsec-ntpd.service /etc/systemd/system/multi-user.target.wants/ntpsec-steptime.service /etc/systemd/system/time-sync.target.wants/ntpsec-wait.service /etc/systemd/system/time-set.target.wants/ntpsec-steptime.service The ntpsec-wait will keep any services from starting that critically depend on system time until the second (non-stepping) ntpd has synchronized. You may not want or need that, it usually adds around 15s to the startup time for me. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel