Re: System Clock is updated before the TAI-UTC offset is applied for PHC source in chrony 6.4.1

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 chrony-users-request-kWFZVVI9zxvPqho9SqqRMmD2FQJk+8+b@public.gmane.org
> with "unsubscribe" in the subject.
> For help email chrony-users-request-kWFZVVI9zxvPqho9SqqRMmD2FQJk+8+b@public.gmane.org
> with "help" in the subject.
> Trouble?  Email [email protected]
>
>

-- 
To unsubscribe email chrony-users-request-kWFZVVI9zxvPqho9SqqRMmD2FQJk+8+b@public.gmane.org 
with "unsubscribe" in the subject.
For help email chrony-users-request-kWFZVVI9zxvPqho9SqqRMmD2FQJk+8+b@public.gmane.org 
with "help" in the subject.
Trouble?  Email [email protected]