lkml.org 
[lkml]   [2024]   [Apr]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [PATCHv2 next] ptp: update gettimex64 to provide ts optionally in mono-raw base.
Date
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)
\
 
 \ /
  Last update: 2024-04-21 20:27    [W:0.030 / U:0.124 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site