is there any time accuracy or performance difference for a server using the offset parameter in chrony.conf?
I recently tried to tune the offset parameter in chrony.conf for a stratum 1 server and guessed wrong on the sign. the oops is clear in the screenshot:
it’s interesting that the offset parameter on that single server line causes the ntppool.org graph to shift closer to zero. I don’t quite understand the purpose of this other than being able to see the offset in the log plot a little better.
does this offset affect anything with the ntppool monitor or anything related to client times?
Please take into account that the monitoring station cannot provide you the time reference, even if its clock is very accurate. There might be, and very likely there is traffic delay asymmetry. For example my server’s offset via IPv4 and IPv6 has even different sign:
I don’t see how the offset parameter would be applicable for a GPS/PPS.
One example where offset might be useful: Say that there is a PPS coming from a radio receiver (WWVB, DCF, etc) and that due to RF propagation delay we know that the PPS is late by, say, 2 msec.
One could use the offset directive to compensate for that 2 msec.
As NTPman suggests, the monitoring station cannot provide an definitive verification of your NTP servers accuracy. Based on previous work I believe the monitoring station is accurate a millisecond. The typical round-trip time between the Newark monitor and your NTP server is 60-80 msec. Since 1/2 RTT is the uncertainty caused by network delay, Newark can at best say that your NTP server is within 30-40 milliseconds
Using the offset directive reduced the apparent offset seen at Newark, but increased the apparent offset seen in Chicago. Neither site should be used to tweak your server.
Properly installed GPS+PPS (well placed antenna is a key factor) on an RPi should keep the RPi within a few microseconds of UTC(USNO).
@NTPman, this is helpful. the two different offset times are a little confusing but indicate the monitoring station is, indeed, not more correct, especially when compared to a nearby gps time source.
@stevesommars, these two monitor logs are super helpful and provide much needed perspective. the Newark monitoring station is the only external reference that shows any observation, so it was unclear earlier exactly what it was saying.
with these two monitoring locations showing different offsets, it is easier to understand that neither monitoring station offset is more important or more correct. They both will have some non-zero offset and that’s a normal, expected result of (a) speed of light over distance and (b) multi-hop network paths.
As you said, neither site should be used to adjust a server, especially since I’ve got a GPS PPS source on my local subnet with the Raspberry Pi. I’ll remove the offset.
The term offset in the two-way messaging scheme refers to an offset between one clock w.r.t. another clock, assuming symmetric delay. this is what is solved for with:
offset = [(t2-t1)+(t3-t4)]/2
but in the chrony.conf documentation, offset refers to an asymmetry in time paths between outbound and return. these are related but not the same. the first is solved for using equation above, the other (in chrony.conf) is an adjustment, or term, placed in the equation above to make offset=0. this is part of the confusion. a better name for the chrony.conf variable might be offset_assymetry.
by the way, that slanted linear segment headed upward at 2020-11-30 was when the public server was still looking at the RPi who had a serial port barf for no clear reason. soon enough that PPS source would have been de-selected as the preferred source and another nearby stratum 1 would have been selected.
the RPi with GPS PPS is great when it works but the serial port is not super reliable. I’m troubleshooting.
this is a good point of reference. it should work.
the Adafruit Ultimate GPS hat has very close (short) hardware connections. I’m using the Ultimate GPS stand-alone board that has about a foot of open wiring to the Pi. this is a source of noise and could be an issue. I switched to the better hardware UART directly to GPIO pins and will try that out for a few days or weeks to see if it is stable. GPS sees 11 satellites.
