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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Tue, 23 Apr 2024 15:22:00 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: David Laight <David.Laight@...LAB.COM>, Mahesh Bandewar (महेश बंडेवार)
 <maheshb@...gle.com>
Cc: Netdev <netdev@...r.kernel.org>, Linux <linux-kernel@...r.kernel.org>,
 David Miller <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>, Eric
 Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>, Richard
 Cochran <richardcochran@...il.com>, Arnd Bergmann <arnd@...db.de>, Sagi
 Maimon <maimon.sagi@...il.com>, Jonathan Corbet <corbet@....net>, John
 Stultz <jstultz@...gle.com>, Mahesh Bandewar <mahesh@...dewar.net>
Subject: RE: [PATCHv2 next] ptp: update gettimex64 to provide ts optionally
 in mono-raw base.

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