Re: Precision Hardware Clocks

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