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

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--1737370858150134285117685957542492483
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE

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 clocktha=
t
the computer can quickly read, knowing the precesion is fraught.



William G. Unruh __|__Hagler Fellow, Distinguished |_Tel:UBC +1(604)822-327=
3
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=
=2Eca
I cannot reply to emails from outlook or hotmail or other microsoft domains=
=2E

On Fri, 16 Jan 2026, Chris Hodgetts wrote:

> [CAUTION: Non-UBC Email]
>
> Why use the PHC =E2=80=9C
>
> 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=E2=80=A6.
> Also I am playing with PTP so it just is what it is and I need the accura=
cy.

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, n=
ot
ns. but it is nice to have bragging rights.

>
> 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.
>
>
>> 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 so=
urce
>> at all. Use a couple of network sources plus the gps (yes, gps under chr=
ony
>> can get down to sub-micro second accuracy so it would always be the prim=
ary
>> 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 unive=
rse
>> would give nice bragging rights, but do you really need that? (and no gp=
s
>> would not give that).
>>
>> Also, on startup the clock should be assumed to be bad for some time. Wh=
y 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)739995=
0
>> UBC, Vancouver,BC _|_ TAMU4242, 578 University Dr  |_ [email protected]=
ca
>> 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 doma=
ins.
>>
>> 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 "uns=
ubscribe" in the subject.
>> For help email chrony-users-request-kWFZVVI9zxvPqho9SqqRMmD2FQJk+8+b@public.gmane.org with "help" in =
the subject.
>> Trouble?  Email [email protected]
>>
>
>
--1737370858150134285117685957542492483--

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