[CAUTION: Non-UBC Email]“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 <unruh@xxxxxxxxxxxxxx> 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 |_ unruh@xxxxxxxxxxxxxx
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 <unruh@xxxxxxxxxxxxxx> 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 |_ unruh@xxxxxxxxxxxxxx
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 chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "help" in the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.
--
To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx with
"unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx with "help" in the
subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.