From nobody Fri May 10 14:35:28 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4VbWdj2Bj2z5JZF1 for ; Fri, 10 May 2024 14:35:53 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from gid2.gid.co.uk (ns0.gid.co.uk [IPv6:2001:470:94de::240]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gid2.gid.co.uk", Issuer "gid2.gid.co.uk" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4VbWdh6tZTz4jyx for ; Fri, 10 May 2024 14:35:52 +0000 (UTC) (envelope-from rb@gid.co.uk) Authentication-Results: mx1.freebsd.org; none Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) by gid2.gid.co.uk (8.15.2/8.15.2) with ESMTP id 44AEZimR070715; Fri, 10 May 2024 15:35:44 +0100 (BST) (envelope-from rb@gid.co.uk) Received: from smtpclient.apple (moriarty.gid.co.uk [194.32.164.17]) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id 44AEZcxT066247; Fri, 10 May 2024 15:35:39 +0100 (BST) (envelope-from rb@gid.co.uk) Content-Type: text/plain; charset=utf-8 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\)) Subject: Re: Precision Hardware Clocks From: Bob Bishop In-Reply-To: <202405100537.44A5boZA076723@critter.freebsd.dk> Date: Fri, 10 May 2024 15:35:28 +0100 Cc: "freebsd-hackers@freebsd.org" , Poul-Henning Kamp Content-Transfer-Encoding: quoted-printable Message-Id: References: <202405100537.44A5boZA076723@critter.freebsd.dk> To: "Josef 'Jeff' Sipek" X-Mailer: Apple Mail (2.3774.500.171.1.1) X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Rspamd-Queue-Id: 4VbWdh6tZTz4jyx Hi, > On 10 May 2024, at 06:37, Poul-Henning Kamp = wrote: >=20 > Josef 'Jeff' Sipek writes: >=20 >> To summarize, the goals/non-goals for this work are: >>=20 >> Goals: >> * read-only interface to various precision hardware clocks (PHCs) >> * support for both absolute time and counter-only PHCs >> * ability to use software like chrony to stabilize system clocks >=20 > I should and will be the last to discourage anybody from having fun > with timekeeping. >=20 > But I do feel a responsibility to point out, that you are trying > to solve already solved problems, in a way that does not work nearly > as well as those solutions. >=20 > Chesterton's fence: Before you throw it out or bypass it, you > should find out why the current timekeeping infrastructure is built > like it is. >=20 > Back in the mists of time, before even I got involved in it, NTPD > did more or less exactly what you propose, because there were no > kernel support for timekeeping, only for adding device drivers, and > it did not work then, and it wont work much better today, for > fundamental and inescapable reasons. >=20 > For starters, exposing the hardware count though a char-dev is going > to be very jittery (=3D time-noise). The "userland->kernel->userland" > context switches are very unpredictable timewise, because it is > anyones guess how many memory operations it will take, even in the > best case. Worse, there is a high risk that you loose the CPU to > another (kernel)thread which is going to /really/ introduce jitter. I can second this. Having in the past tried to do time-sensitive machine = control that way, the jitter was too bad to maintain a few tens of = milliseconds. You might do an order of magnitude better today but it=E2=80= =99s still nowhere near good enough for modern timekeeping. > That is why the PPS-API, timecounters and kernel_pll exists: To > keep the "real-time" aspect of the timekeeping firmly inside the > kernel and undisturbed by userland and lower priority kernel > activities. >=20 > Unless you can expose the hardware directly to userland, via mmap(2), > timekeeping in userland is simply not going to perform. >=20 > With that said, a lot of our timekeeping is stuff I wrote 25 years > old, and it is absolutely due for both a rethink and a refresh, but > if you decide to throw it all out and start from fresh, you will > not get to the interesting parts for years. >=20 > So before you continue, at the very least, read this: >=20 > https://papers.freebsd.org/2002/phk-timecounters/ >=20 > And you should think a LOT about page 91 in this one too: >=20 > = https://www.am1.us/wp-content/uploads/Documents/U11625_VIG-TUTORIAL.pdf >=20 > (The other 307 pages are also interesting :-) >=20 > Poul-Henning > FreeBSD TimeLord (retired) >=20 > --=20 > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe =20 > Never attribute to malice what can adequately be explained by = incompetence. >=20 -- Bob Bishop rb@gid.co.uk