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

From: David Laight
Date: Sun Apr 21 2024 - 14:27:51 EST


From: Mahesh Bandewar
> Sent: 18 April 2024 05:27
>
> The current implementation of PTP_SYS_OFFSET_EXTENDED provides
> PHC reads in the form of [pre-TS, PHC, post-TS]. These pre and
> post timestamps are useful to measure the width of the PHC read.
> However, the current implementation provides these timestamps in
> CLOCK_REALTIME only. Since CLOCK_REALTIME is disciplined by NTP
> or NTP-like service(s), the value is subjected to change. This
> makes some applications that are very sensitive to time change
> have these timestamps delivered in different time-base.
...

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.

If I understand the intent of the UAPI, a possibly solution is
to get the offset between CLOCK_REALTIME and CLOCK_MONATONIC and
ensure the same offset is added CLOCK_MONATONIC for the pre- and
post- timestamps.

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.
It really would be nice if those big adjustments didn't affect
CLOCK_MONATONIC.
(as an example try sending RTP audio every 20ms)

David

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