Re: [PATCH v2 0/6] timekeeping: Reduce magnitude of ntp_error

[David Woodhouse]

On Fri, 2026-11-06 at 09:44 +0100, Rodolfo Giometti wrote:
> On 06/11/2026 04:24, David Woodhouse wrote:
> > I think I reordered and reworded things as agreed with Rodolfo; please
> > shout if I screwed something up. What's sitting behind this in
> > https://git.infradead.org/users/dwmw2/linux.git/shortlog/refs/heads/ffclock
> > is the timekeeping reference stuff for importing/exporting vmclock, and
> > preserving timekeeping across KHO:
> 
> No, the 5/6 and 6/6 split is what we agreed, thanks. On 6/6 I'm still
> missing the ntpd side, see my reply there.

Ack, thanks. Do you know who we should talk to? Should we be adding
them to MAINTAINERS to be Cc'd, like we did Miroslav?

> > The !NO_HZ_COMMON dependency can sit around for a little while longer
> > until the series above is actually applied, and it can note the
> > actually commit ID of its dependencies (which I think we agreed is just
> > patches 1 & 2 of the series above). I'll probably round it up with the
> > other PPS stuff I haven't quite got publishable yet, improving the
> > filtering and then working on counter-based capture and UAPI.
> 
> AFAIK we agreed on patches 1-4: the tickless run you did for me
> (rodolfo-14-tickless-1hz) had all four applied. If 1 and 2 alone are
> enough, could you put numbers for that in the commit message too?

It's the same. Patches 1 and 2 eliminate the cases where I *saw*
ntp_error grow large, which means that the code to *eliminate* it
basically didn't get much exercise. If I'd seen anything else introduce
any significant value into ntp_error, I'd have fixed that too. The
draining is belt-and-braces, and should only really come into play if
there are long tickless periods.

I'm travelling ATM but can do the run again with just those patches
when I get home in a couple of weeks, just to be sure.

> And for the UAPI, an RFC first please. :-)

Sure. For your visibility, on my TODO list for PPS is the stuff that
nerd-sniped me as I was testing with hardpps:

 • tracepoints to export the pulse data (so captures from real hardware
   can be replayed offline to experiment with filters):
   https://git.infradead.org/users/dwmw2/linux.git/commitdiff/hardpps-trace
 • a simulator for evaluating filters against those captures:
   https://git.infradead.org/pps-lab.git
 • improving the filtering itself (I've been playing with a few things
   starting with actually implementing median-of-three, but then
   ditching it for better outlier rejection, and going down a rabbit
   hole of other things like a constant +120ns bias from hardpps which
   chrony doesn't show on the *same* pulse data...)
 • continuous frequency tracking.

And orthogonally the things I originally wanted to look at:

 • counter-based capture: report the (counter, CLOCK_REALTIME) pair to
   userspace instead of throwing the counter value away, and let
   hardpps consume it directly
 • support for hardware which latches the clocksource counter on the
   pulse edge (no interrupt latency in the timestamp at all; such
   hardware exists and currently gets shoehorned through PTP EXTTS)

I'll probably try to come up with a UAPI RFC in the next couple of
weeks after I get home from KVM Forum.

Attachment: smime.p7s
Description: S/MIME cryptographic signature