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]
Message-ID: <875xw8uscn.ffs@tglx>
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



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ