Messages in this thread | | | From | David Laight <> | Subject | RE: [PATCHv2 next] ptp: update gettimex64 to provide ts optionally in mono-raw base. | Date | Sun, 21 Apr 2024 18:27:01 +0000 |
| |
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)
| |