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: > > Josef 'Jeff' Sipek writes: > >> To summarize, the goals/non-goals for this work are: >> >> 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 > > I should and will be the last to discourage anybody from having fun > with timekeeping. > > 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. > > 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. > > 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. > > For starters, exposing the hardware count though a char-dev is going > to be very jittery (= 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’s 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. > > Unless you can expose the hardware directly to userland, via mmap(2), > timekeeping in userland is simply not going to perform. > > 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. > > So before you continue, at the very least, read this: > > https://papers.freebsd.org/2002/phk-timecounters/ > > And you should think a LOT about page 91 in this one too: > > https://www.am1.us/wp-content/uploads/Documents/U11625_VIG-TUTORIAL.pdf > > (The other 307 pages are also interesting :-) > > Poul-Henning > FreeBSD TimeLord (retired) > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > -- 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>