Re: [PATCH v4 2/4] pps: Drop the !NO_HZ_COMMON dependency from NTP_PPS

[David Woodhouse]

On Thu, 2026-10-01 at 10:20 +0200, Rodolfo Giometti wrote:
> Hi David,
> 
> On 30/09/2026 20:24, David Woodhouse wrote:
> > On Wed, 2026-09-30 at 15:05 +0100, David Woodhouse wrote:
> > > [...] But
> > > I don't think we're ever going to be allowed to do it that way in
> > > entry.S but the *hardware-captured* stamps will want the same handling,
> > > so I wanted to prototype it anyway.
> 
> Hardware-captured stamps are something I'd really like to see in the PPS
> subsystem. When you get there, I think it should be its own series,
> discussed together with the raw counter export you mentioned on the
> 28th, since both change what a PPS driver hands to the core and what
> userspace gets back. As I said for the export, I'd prefer to agree on
> the interface first.

Yeah, I'm trying to split things up as much as I can for upstreaming
simple series one at a time, while also keeping the future/RFC parts in
the working tree to be sure that it *does* all come together as a
coherent whole in the end.

The hardware-captured stamps aren't even on my radar for actual
*typing* yet, as I haven't got the hardware yet. (Which is partly why I
was simulating it with the entry.S capture).

I think *exporting* the raw counter values is slightly orthogonal and
can happen first. Even software-captured clock values *do* have a
counter read that goes alongside them.

Right now, we have userspace trying to discipline the kernel's
CLOCK_REALTIME, varying as it does around the "ideal" time that the
kernel wants to report. Especially on tickless kernels.

Even today, userspace could discipline the *counter*, free of any
feedback loops, and then just tell the kernel the result.

That just needs us to (optionally) report the counter value alongside
the clock value for PTP and PPS timestamps. The former is what Arthur
is adding to the PTP userspace API in 
https://lore.kernel.org/all/20260717065924.2556-1-akiyano@xxxxxxxxxx/

Carrying the raw counter value (and csid) in the pps_event_time
snapshot inside the kernel is easy enough. I haven't yet looked at what
the userspace API should look like for PPS. There was a discussion
somewhere about how we convert kernel CSID enum values to userspace.
You may have opinions...
https://lore.kernel.org/all/1a5c0883140d470657b2cba24b964f5ce71b9a15.camel@xxxxxxxxxxxxx/

> > We don't actually do *any* filtering. Even pps_phase_filter_get() is
> > just using the first sample, with a comment:
> > 
> > 	/* TODO: test various filters */
> > 
> > Looking closer at the actual captures, even Mills's median-of-three
> > wouldn't save us here when two of the three pulses are outliers. We'd
> > want an ongoing frequency estimation.
> > 
> > But that's definitely a problem for another day.
> 
> Agreed, but I'm interested in it too. Your setup, with the per-pulse
> captures, looks like a good way to evaluate a filter, so if you or
> anyone else picks it up, please Cc me and I'll be glad to review it.

Yeah, this box just lurks on my desk waiting for a chance to do useful
things, so I'm happy to do test runs with any candidate fixes. I was
kind of writing this pattern off as an artefact of the test itself — I
*deliberately* synced it to do its data collection right after a pulse
(trying to do its work *between* pulses, rather than interfering).

But I guess if the main system clock is tied to the PPS (because, er,
why were we here in the first place?) then *any* periodic work could
have the same kind of beat effect, lining up with 1 in N of the 256s
pps_shift periods and triggering that ADSR pattern. Not just my test
which was deliberately synced to a *pulse*.

FWIW I think I have enough data captured from the existing runs that I
can do retrospective "what if?" analysis of how filters *would have*
worked. Another benefit of capturing the raw counter not the feedback
loop :)

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