RE: [PATCHv2 next] ptp: update gettimex64 to provide ts optionally in mono-raw base.

[David Laight]

From: Thomas Gleixner
> Sent: 23 April 2024 01:25
...
> >> It really would be nice if those big adjustments didn't affect
> >> CLOCK_MONATONIC. (as an example try sending RTP audio every 20ms)
> 
> They don't affect CLOCK_MONATONIC at all because there is no such clock :)
> 
> > Hmm, probably this is out of context for this patch and probably a
> > question for the time maintainers / experts?
> 
> The quantity of the initial frequency adjustments depends on the
> accuracy of the initial clock frequency calibration which is on most
> sane systems within +/- 500ppm.
> 
>      500ppm of 20ms == 10us
> 
> If the clock calibration is off by a larger margin then that needs to be
> fixed.

The initial adjustment depends on the accuracy of the initial RTC
value read from the local hardware.
This is unlikely to be more accurate than 1 second and can easily
be a few seconds out.

Correcting this causes NTP to adjust the clock at its maximum drift
rate for a while - I'm sure I've seen this happen for minutes.
Once this completes there is a 'step change' in the frequency adjustment.

Once the system has been running for a while the adjustments are minor.
Time runs alternately fast and slow to maintain long term accuracy.

This is noticeable if you use schedule_hrtimeout_range(,, HRTIMER_MODE_ABS)
to synchronize to an accurate external clock [1].
(Without NTP it has to adjust for temperature changing the frequency.)

	David

[1] Imagine some hardware that counts usecs after the 1-second GPS pulse.
and a driver that adjusts a sleep to wake up when that count is between
(say) 400 and 600.
Using a timer and a single readl() is far faster than taking an interrupt.
(In our case it is a 10ms pulse derived from the clock recovered from
an E1/T1 telecoms link.)

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)