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 02:24:59 +0200 |
| |
On Mon, Apr 22 2024 at 15:04, Mahesh Bandewar (महेश बंडेवार) wrote: > On Sun, Apr 21, 2024 at 11:27 AM David Laight <David.Laight@aculab.com> wrote: >> >> Isn't using CLOCK_REALTIME just a big bug? >> As well as minor 'corrections' done by NTP it suffers from >> major time-warps that can jump in either direction by arbitrary amounts. >> > Yes, this arbitrary jump in either direction is a problem and hence > the proposed update. However, since it's a UAPI and there could be use > cases that are happy with the current implementation, we can't break > them. Of course the use case that I'm bringing in (and probably what > you have in mind) differs but backward compatibility needs to be > maintained.
It depends on what you are trying to do. You cannot adjust CLOCK_REALTIME/TAI without knowing the current time, right?
So just declaring that this is a big bug and a problem is as wrong as it gets. It's obviously not the right thing for all use cases, but that makes the legitimate use cases not wrong.
>> This doesn't solve the problem of the NTP adjusted clock always >> running slightly slow or fast. >> The big NTP errors happen in the first (IIRC up to ~20 mins after boot) >> when the system clock is being synchronised. > > Yes, a big step is a high possibility at the beginning (at boot) but > smaller steps as well as ppm adjustments are real possibilities > throughout and hence CLOCK_REALTIME and CLOCK_MONOTONIC are affected. > By adding the timestamps in CLOCK_MONOTONIC_RAW (as proposed in this > patch) should address this issue. > >> 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.
It's clearly documented that CLOCK_MONOTONIC and CLOCK_REALTIME (and therefore CLOCK_BOOTTIME and CLOCK_TAI) are strictly based on the same frequency and only differ by offsets. So there is nothing to fix and change.
Thanks,
tglx
| |