Date: Fri, 10 May 2024 15:35:28 +0100 From: Bob Bishop <rb@gid.co.uk> To: "Josef 'Jeff' Sipek" <jeffpc@josefsipek.net> Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@FreeBSD.org>, Poul-Henning Kamp <phk@phk.freebsd.dk> Subject: Re: Precision Hardware Clocks Message-ID: <D8EEAD9E-3EFE-4296-9AA3-6A1434F3A40F@gid.co.uk> In-Reply-To: <202405100537.44A5boZA076723@critter.freebsd.dk> References: <Zj1c1p-GQ0cHY_5f@satis> <202405100537.44A5boZA076723@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, > On 10 May 2024, at 06:37, Poul-Henning Kamp <phk@phk.freebsd.dk> = 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D8EEAD9E-3EFE-4296-9AA3-6A1434F3A40F>