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

Chris Hodgetts <[email protected]> Sat, 17 Jan 2026 09:49:06 +1300
Newsgroups gmane.comp.time.chrony.user
Message-ID <[email protected]>
--Apple-Mail=_EAD27369-236F-4476-B096-9AB9551C0CA7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

=E2=80=9CAgreed 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=E2=80=99m 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.=E2=80=9D

> On 17 Jan 2026, at 09:35, Bill Unruh <[email protected]> wrote:
>=20
> 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.
>=20
>=20
>=20
> 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.
>=20
> On Fri, 16 Jan 2026, Chris Hodgetts wrote:
>=20
>> [CAUTION: Non-UBC Email]
>>=20
>> Why use the PHC =E2=80=9C
>>=20
>> 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
>>=20
>>=20
>> Because why not=E2=80=A6.
>> Also I am playing with PTP so it just is what it is and I need the =
accuracy.
>=20
> 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.
>=20
>>=20
>> But look at that system time=E2=80=A6. It=E2=80=99s in the =
nanoseconds of accuracy - just because - why not have the best if you =
can get the best.
>>=20
>>=20
>>> On 16 Jan 2026, at 19:56, Bill Unruh <[email protected]> wrote:
>>>=20
>>> 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).
>>>=20
>>> 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.
>>>=20
>>> 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.
>>>=20
>>> On Fri, 16 Jan 2026, Simon Plackett wrote:
>>>=20
>>>> [CAUTION: Non-UBC Email]
>>>>=20
>>>> Hi,
>>>>=20
>>>> 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.
>>>>=20
>>>> I had previously been using the ethernet NIC clock as a time source
>>>> with ptp4l and phc2sys, which worked fine.
>>>>=20
>>>> During the upgrade I changed to leapseclist from leapsectz as the
>>>> latter does not work on Trixie.
>>>>=20
>>>> 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.
>>>>=20
>>>> 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
>>>>=20
>>>> I can see this using systemctl status chrony or using journalctl.
>>>>=20
>>>> I have currently turned PHC off again - but happy to turn back on =
and
>>>> send any logs etc that might be useful.
>>>>=20
>>>> The other source is PPS from GPS, which is even more accurate on =
the
>>>> new versions :-)
>>>>=20
>>>> Thanks
>>>> Simon
>>>>=20
>>>> --
>>>> 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]
>>>>=20
>>>>=20
>>>=20
>>> --
>>> 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]
>>>=20
>>=20


--Apple-Mail=_EAD27369-236F-4476-B096-9AB9551C0CA7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html aria-label=3D"message body"><head><meta http-equiv=3D"content-type" =
content=3D"text/html; charset=3Dutf-8"></head><body =
style=3D"overflow-wrap: break-word; -webkit-nbsp-mode: space; =
line-break: after-white-space;"><span style=3D"font-family: =
-webkit-standard; font-size: medium;">=E2=80=9CAgreed 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=E2=80=99m =
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.=E2=80=9D</span><br =
id=3D"lineBreakAtBeginningOfMessage"><div><br><blockquote =
type=3D"cite"><div>On 17 Jan 2026, at 09:35, Bill Unruh =
&lt;[email protected]&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div><div>Well, the scatter is 9ns. =
The problem is that the interrupt program takes a<br>while to load, and =
to adjust the clock. Ie, without an independent clockthat<br>the =
computer can quickly read, knowing the precesion is =
fraught.<br><br><br><br>William G. Unruh __|__Hagler Fellow, =
Distinguished |_Tel:UBC +1(604)822-3273<br>Physics&amp;Astronomy _|__ =
Research Prof, IQSE &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|__ =
&nbsp;US +1(979)7399950<br>UBC, Vancouver,BC _|_ TAMU4242, 578 =
University Dr &nbsp;|_ [email protected]<br>Canada V6T 1Z1 =
____|__College Stn, Tx, USA 77843 =
&nbsp;_|_www.theory.physics.ubc.ca<br>I cannot reply to emails from =
outlook or hotmail or other microsoft domains.<br><br>On Fri, 16 Jan =
2026, Chris Hodgetts wrote:<br><br><blockquote type=3D"cite">[CAUTION: =
Non-UBC Email]<br><br>Why use the PHC =E2=80=9C<br><br>chronyc =
tracking<br>Reference ID &nbsp;&nbsp;&nbsp;: 50484330 (PHC0)<br>Stratum =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;: 1<br>Ref time (UTC) =
&nbsp;: Fri Jan 16 08:40:40 2026<br>System time =
&nbsp;&nbsp;&nbsp;&nbsp;: 0.000000007 seconds fast of NTP time<br>Last =
offset &nbsp;&nbsp;&nbsp;&nbsp;: -0.000000014 seconds<br>RMS offset =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;: 0.000000029 seconds<br>Frequency =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;: 14.710 ppm slow<br>Residual freq =
&nbsp;&nbsp;: +0.000 ppm<br>Skew =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;: =
0.017 ppm<br>Root delay &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;: 0.000000001 =
seconds<br>Root dispersion : 0.000000544 seconds<br>Update interval : =
1.0 seconds<br>Leap status &nbsp;&nbsp;&nbsp;&nbsp;: =
Normal<br><br><br>Because why not=E2=80=A6.<br>Also I am playing with =
PTP so it just is what it is and I need the =
accuracy.<br></blockquote><br>I know the feeling. I got interested in =
ntp and chrony for the same reason. My<br>own need for time precision =
and accuracy is at best in the seconds range, not<br>ns. but it is nice =
to have bragging rights.<br><br><blockquote type=3D"cite"><br>But look =
at that system time=E2=80=A6. It=E2=80=99s in the nanoseconds of =
accuracy - just because - why not have the best if you can get the =
best.<br><br><br><blockquote type=3D"cite">On 16 Jan 2026, at 19:56, =
Bill Unruh &lt;[email protected]&gt; wrote:<br><br>Although this is =
certainly a pain, I wonder why you are using the PHC source<br>at all. =
Use a couple of network sources plus the gps (yes, gps under =
chrony<br>can get down to sub-micro second accuracy so it would always =
be the primary<br>source, except if it loast tracking, in which case the =
fallback would be the<br>time from the network source, which would be in =
the microseconds, or 10s of<br>microseconds accuracy.<br>What accuracy =
do you need? I know that 1 second in the life of the universe<br>would =
give nice bragging rights, but do you really need that? (and no =
gps<br>would not give that).<br><br>Also, on startup the clock should be =
assumed to be bad for some time. Why are<br>you switching it off at =
all?If you want accurate time, let the clock and<br>chrony run for as =
long as possible.<br><br>William G. Unruh __|__Hagler Fellow, =
Distinguished |_Tel:UBC +1(604)822-3273<br>Physics&amp;Astronomy _|__ =
Research Prof, IQSE &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|__ =
&nbsp;US +1(979)7399950<br>UBC, Vancouver,BC _|_ TAMU4242, 578 =
University Dr &nbsp;|_ [email protected]<br>Canada V6T 1Z1 =
____|__College Stn, Tx, USA 77843 =
&nbsp;_|_www.theory.physics.ubc.ca<br>I cannot reply to emails from =
outlook or hotmail or other microsoft domains.<br><br>On Fri, 16 Jan =
2026, Simon Plackett wrote:<br><br><blockquote type=3D"cite">[CAUTION: =
Non-UBC Email]<br><br>Hi,<br><br>Before I send a lot of detail I =
wondered if anyone had seen this<br>phenomenon. I have just upgraded my =
local chrony server to Trixie on<br>RPI 5 with chrony 4.6.1.<br><br>I =
had previously been using the ethernet NIC clock as a time =
source<br>with ptp4l and phc2sys, which worked fine.<br><br>During the =
upgrade I changed to leapseclist from leapsectz as the<br>latter does =
not work on Trixie.<br><br>The issue is that on startup the system clock =
is set by the PHC source<br>before the TAI-UTC adjustment has been =
applied which means it jumps<br>36+ seconds one way and then back again =
during the startup. This<br>obviously trashes the PHC as a source, and =
it didn't happen<br>previously.<br><br>Essentially PHC is chosen as the =
source, updates system clock (wrong<br>by ~37s) then the TAI-UTC =
adjustment is found which causes system time<br>to jump again in the =
opposite direction by ~37s<br><br>I can see this using systemctl status =
chrony or using journalctl.<br><br>I have currently turned PHC off again =
- but happy to turn back on and<br>send any logs etc that might be =
useful.<br><br>The other source is PPS from GPS, which is even more =
accurate on the<br>new versions =
:-)<br><br>Thanks<br>Simon<br><br>--<br>To unsubscribe email =
chrony-users-request-kWFZVVI9zxvPqho9SqqRMmD2FQJk+8+b@public.gmane.org<br>with "unsubscribe" in the =
subject.<br>For help email =
chrony-users-request-kWFZVVI9zxvPqho9SqqRMmD2FQJk+8+b@public.gmane.org<br>with "help" in the =
subject.<br>Trouble? &nbsp;Email =
[email protected]<br><br><br></blockquote><br>--<br>To =
unsubscribe email chrony-users-request-kWFZVVI9zxvPqho9SqqRMmD2FQJk+8+b@public.gmane.org with =
"unsubscribe" in the subject.<br>For help email =
chrony-users-request-kWFZVVI9zxvPqho9SqqRMmD2FQJk+8+b@public.gmane.org with "help" in the =
subject.<br>Trouble? &nbsp;Email =
[email protected]<br><br></blockquote><br></blockquote></di=
v></div></blockquote></div><br></body></html>=

--Apple-Mail=_EAD27369-236F-4476-B096-9AB9551C0CA7--

-- 
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]