Messages in this thread | | | From | Thomas Gleixner <> | Subject | RE: [PATCHv2 next] ptp: update gettimex64 to provide ts optionally in mono-raw base. | Date | Tue, 23 Apr 2024 15:22:00 +0200 |
| |
On Tue, Apr 23 2024 at 09:22, David Laight wrote: > From: Thomas Gleixner >> 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.
The initial value of CLOCK_REALTIME depends on the RTC value, but not the initial frequency and the frequency is the only thing which matters for CLOCK_MONOTONIC.
> This is unlikely to be more accurate than 1 second and can easily > be a few seconds out.
Halfways sane RTCs drift in the range of +/- 5 seconds per day. But that's not a problem if your NTP daemon is configured correctly because it will step CLOCK_REALTIME right away when it's off more than 1 second.
Also correctly configured NTP daemons keep track of the drift and reuse the last observed drift value which makes them stabilize quickly if the initial frequency value which has been calibrated / determined by the kernel is halfways accurate. It takes 5 seconds on my laptop from starting chrony until it's stable.
Sure you can configure NTP in weird ways, but that's not a kernel problem.
Thanks,
tglx
| |