“Agreed in the general case. In my setup the PHC is disciplined via hardware-timestamped PTP from a GPS-locked grandmaster, so the system clock is aligned to a local hardware reference rather than software interrupt timing. I’m not claiming absolute UTC accuracy at single-digit nanoseconds, but the relative system-to-PHC and system-to-GM alignment is demonstrably in the tens-of-ns range.”
> On 17 Jan 2026, at 09:35, Bill Unruh <[email protected]> wrote: > > Well, the scatter is 9ns. The problem is that the interrupt program takes a > while to load, and to adjust the clock. Ie, without an independent clockthat > the computer can quickly read, knowing the precesion is fraught. > > > > William G. Unruh __|__Hagler Fellow, Distinguished |_Tel:UBC +1(604)822-3273 > Physics&Astronomy _|__ Research Prof, IQSE |__ US +1(979)7399950 > UBC, Vancouver,BC _|_ TAMU4242, 578 University Dr |_ [email protected] > Canada V6T 1Z1 ____|__College Stn, Tx, USA 77843 _|_www.theory.physics.ubc.ca > I cannot reply to emails from outlook or hotmail or other microsoft domains. > > On Fri, 16 Jan 2026, Chris Hodgetts wrote: > >> [CAUTION: Non-UBC Email] >> >> Why use the PHC “ >> >> chronyc tracking >> Reference ID : 50484330 (PHC0) >> Stratum : 1 >> Ref time (UTC) : Fri Jan 16 08:40:40 2026 >> System time : 0.000000007 seconds fast of NTP time >> Last offset : -0.000000014 seconds >> RMS offset : 0.000000029 seconds >> Frequency : 14.710 ppm slow >> Residual freq : +0.000 ppm >> Skew : 0.017 ppm >> Root delay : 0.000000001 seconds >> Root dispersion : 0.000000544 seconds >> Update interval : 1.0 seconds >> Leap status : Normal >> >> >> Because why not…. >> Also I am playing with PTP so it just is what it is and I need the accuracy. > > I know the feeling. I got interested in ntp and chrony for the same reason. My > own need for time precision and accuracy is at best in the seconds range, not > ns. but it is nice to have bragging rights. > >> >> But look at that system time…. It’s in the nanoseconds of accuracy - just >> because - why not have the best if you can get the best. >> >> >>> On 16 Jan 2026, at 19:56, Bill Unruh <[email protected]> wrote: >>> >>> Although this is certainly a pain, I wonder why you are using the PHC source >>> at all. Use a couple of network sources plus the gps (yes, gps under chrony >>> can get down to sub-micro second accuracy so it would always be the primary >>> source, except if it loast tracking, in which case the fallback would be the >>> time from the network source, which would be in the microseconds, or 10s of >>> microseconds accuracy. >>> What accuracy do you need? I know that 1 second in the life of the universe >>> would give nice bragging rights, but do you really need that? (and no gps >>> would not give that). >>> >>> Also, on startup the clock should be assumed to be bad for some time. Why >>> are >>> you switching it off at all?If you want accurate time, let the clock and >>> chrony run for as long as possible. >>> >>> William G. Unruh __|__Hagler Fellow, Distinguished |_Tel:UBC +1(604)822-3273 >>> Physics&Astronomy _|__ Research Prof, IQSE |__ US +1(979)7399950 >>> UBC, Vancouver,BC _|_ TAMU4242, 578 University Dr |_ [email protected] >>> Canada V6T 1Z1 ____|__College Stn, Tx, USA 77843 >>> _|_www.theory.physics.ubc.ca >>> I cannot reply to emails from outlook or hotmail or other microsoft domains. >>> >>> On Fri, 16 Jan 2026, Simon Plackett wrote: >>> >>>> [CAUTION: Non-UBC Email] >>>> >>>> Hi, >>>> >>>> Before I send a lot of detail I wondered if anyone had seen this >>>> phenomenon. I have just upgraded my local chrony server to Trixie on >>>> RPI 5 with chrony 4.6.1. >>>> >>>> I had previously been using the ethernet NIC clock as a time source >>>> with ptp4l and phc2sys, which worked fine. >>>> >>>> During the upgrade I changed to leapseclist from leapsectz as the >>>> latter does not work on Trixie. >>>> >>>> The issue is that on startup the system clock is set by the PHC source >>>> before the TAI-UTC adjustment has been applied which means it jumps >>>> 36+ seconds one way and then back again during the startup. This >>>> obviously trashes the PHC as a source, and it didn't happen >>>> previously. >>>> >>>> Essentially PHC is chosen as the source, updates system clock (wrong >>>> by ~37s) then the TAI-UTC adjustment is found which causes system time >>>> to jump again in the opposite direction by ~37s >>>> >>>> I can see this using systemctl status chrony or using journalctl. >>>> >>>> I have currently turned PHC off again - but happy to turn back on and >>>> send any logs etc that might be useful. >>>> >>>> The other source is PPS from GPS, which is even more accurate on the >>>> new versions :-) >>>> >>>> Thanks >>>> Simon >>>> >>>> -- >>>> To unsubscribe email [email protected] >>>> with "unsubscribe" in the subject. >>>> For help email [email protected] >>>> with "help" in the subject. >>>> Trouble? Email [email protected]. >>>> >>>> >>> >>> -- >>> To unsubscribe email [email protected] with >>> "unsubscribe" in the subject. >>> For help email [email protected] with "help" in the >>> subject. >>> Trouble? Email [email protected]. >>> >>
