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] [thread-next>] [day] [month] [year] [list]

Message-ID: <f2ac461445f44addb521ef79ecedc584@AcuMS.aculab.com>
Date: Tue, 23 Apr 2024 09:22:06 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Thomas Gleixner' <tglx@...utronix.de>,
	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.

From: Thomas Gleixner
> Sent: 23 April 2024 01:25
...
> >> It really would be nice if those big adjustments didn't affect
> >> CLOCK_MONATONIC. (as an example try sending RTP audio every 20ms)
> 
> They don't affect CLOCK_MONATONIC at all because there is no such clock :)
> 
> > Hmm, probably this is out of context for this patch and probably a
> > question for the time maintainers / experts?
> 
> 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.
This is unlikely to be more accurate than 1 second and can easily
be a few seconds out.

Correcting this causes NTP to adjust the clock at its maximum drift
rate for a while - I'm sure I've seen this happen for minutes.
Once this completes there is a 'step change' in the frequency adjustment.

Once the system has been running for a while the adjustments are minor.
Time runs alternately fast and slow to maintain long term accuracy.

This is noticeable if you use schedule_hrtimeout_range(,, HRTIMER_MODE_ABS)
to synchronize to an accurate external clock [1].
(Without NTP it has to adjust for temperature changing the frequency.)

	David

[1] Imagine some hardware that counts usecs after the 1-second GPS pulse.
and a driver that adjusts a sleep to wake up when that count is between
(say) 400 and 600.
Using a timer and a single readl() is far faster than taking an interrupt.
(In our case it is a 10ms pulse derived from the clock recovered from
an E1/T1 telecoms link.)

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