Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 10 May 2024 05:37:50 +0000
From:      "Poul-Henning Kamp" <phk@phk.freebsd.dk>
To:        "Josef 'Jeff' Sipek" <jeffpc@josefsipek.net>
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: Precision Hardware Clocks
Message-ID:  <202405100537.44A5boZA076723@critter.freebsd.dk>
In-Reply-To: <Zj1c1p-GQ0cHY_5f@satis>
References:  <Zj1c1p-GQ0cHY_5f@satis>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?202405100537.44A5boZA076723>