Where the precision actually lives
A GPS receiver hands you time twice, in two completely different currencies, and almost every tuning mistake comes from confusing them.
NMEA tells you which second it is
Section titled “NMEA tells you which second it is”The receiver computes the time precisely, and then it has to shift a text sentence out of a serial port. At 9600 baud that takes hundreds of milliseconds, and the delay wobbles from second to second depending on how many sentences are enabled and what the CPU was doing.
Our NMEA-derived time sat +160 ms off, with hundreds of microseconds of noise. That’s not the receiver being bad. That’s a UART being a UART.
PPS tells you exactly when that second began
Section titled “PPS tells you exactly when that second began”The same receiver also raises a single electrical edge at the top of every second, accurate to nanoseconds. No protocol, no encoding, no serial port — just a voltage going high at the instant the second starts.
That edge is where every nanosecond of your accuracy comes from. All of it.
What that means in practice
Section titled “What that means in practice”chrony uses them together, and the division of labour is total:
refclock SHM 0 refid GPS ... noselect # NMEA: labels the second. Never the time source.refclock PPS /dev/pps0 ... lock GPS # PPS: IS the time source.The NMEA source is marked noselect — chrony is explicitly told never to use it
to set the clock. Its only job is to answer “which second is this pulse?”, and
for that it merely has to be within half a second. It has an entire half-second
of slack.
Baud rate, sentence count, SBAS, update rate — all of it lives on the NMEA side of the wall. Tune it if you enjoy tuning. Just don’t expect the clock to notice.