Please enable method to disable tickless kernel and to enable kernel PPS

[ghost]

I've been following the "Change to 250hz and voluntary preemption" thread with interest, as it has potential benefits for NTP server applications. I was wondering if it would also be possible to enable the disabling of the tickless kernel ('nohz=off' in cmdline.txt or config.txt) that works for other distros but for some reason doesn't appear to work on the Pi, and also to enable the 'Device Drivers > PPS support > PPS kernel consumer support' option, which allows full kernel pulse-per-second ability (assuming these have no knock-on effect to stability, speed etc).

These two changes, coupled with any increase in timer frequency, would save on custom kernel compiling with, I hope, little or no impact on other uses.

[Ferroin]

The default kernel shouldn't be running tickless on at least the original Pi's (you can't safely run tickless on a single processor system and still have working accounting). I'm not 100% certain, but I think that even tickless idle is turned off at compile time anyway.

It might be worth noting that where I work our DHCP servers are RPi's, and they run as NTP peers, and I've never seen them more than a dozen PPM out of sync with each other or the local NTP servers after the initial sync, despite using stock Raspbian kernels.

[ghost]

The armv6 kernel is set to 'tickless idle' by default. Regardless, enabling 'PPS kernel consumer support' should have no impact on people not using PPS but should show a useful and important improvement for those who want an extremely accurate time server either for personal use or to add to the NTP pool. Certainly in terms of kernel PPS versus NTP PPS, kernel PPS is measurably more stable when offset and jitter are checked with ntpq.

[Ferroin]

OK, I'm actually kind of curious how much tickless idle would impact jitter, you're getting woken up once per second anyway by the PPS interfafce, which would start the scheduler tick.

Secondarily, unless you're doing scientific work, you almost certainly don't need better than millisecond accuracy for a local time server, so the argument is really for people who want to use it as an open NTP server.

I can't really personally argue how much impact the PPS support might have on normal users, but you should keep in mind that even a few kilobytes of extra ram being used by the kernel does have an impact for regular users.

Regardless, I'm not personally a developer (just someone who has a lot of experience with the Linux kernel in general), so I'm not the person you would need to convince.

[ghost]

My argument is for sub-millisecond timing. Those of us who are interested in/obsessed with such things can do very nicely with the Pi's current kernel but with kernel PPS enabled nanosecond accuracy is possible. I can't see a reason for not enabling PPS kernel consumer support as, as far as I can tell, it will do nothing unless the pps-core and pps-gpio modules are enabled from the device tree. If, as you say, tickless idle is being prevented by the PPS signal, my request for nohz=off can most likely be disregarded.

[Ferroin]

I'm not 100% certain about how PPS interacts with tickless idle. Absolute best case scenario, it just gets offset by the amount of time it takes to get the tick running again (not sure how long this is on the Pi, but probably much less than 1ms), worst case there's jitter in the wakeup routine because of tickless idle.

As far as just enabling it, the issue is not as likely to be processor usage, but memory usage. Absolute best case scenario, this all fits such that the memory footprint at runtime is no bigger. However, that's pretty unlikely, and I would expect at least a 4k increase in memory consumption. Whether that would be enough to make the developers not want to include this or not, I can't say.

Like I said though, I'm not the one you need to convince.

[ghost]

At this point I think the opinion of a developer would be useful, at least on the PPS request. The tickless idle thing can probably be taken care of by disabling all energy saving features and relying on the PPS signal to keep the Pi from idling.

[P33M]

Is PPS input (on a GPIO) from e.g. a GPS module or radio time decoder?

[Ferroin]

@P33M Usually I've seen some people do up custom high precision timers for it, and it's sometimes driven directly by an atomic clock, but both cases are usually expensive and time consuming to do right, and as such aren't anywhere near as common as a GPS/GLONASS/Galileo module or a radio time decoder.

[ghost]

@P33M Yes. PPS can be supplied from either of those sources, the square wave output of a real time clock, through any number of clock generators, and other ways.

[ghost]

NTP documentation is not terribly helpful or up to date, but here are a couple of links that may clarify PPS and its usefulness:

NTP's PPS reference driver: https://www.eecis.udel.edu/~mills/ntp/html/drivers/driver22.html
Details of the PPSAPI: https://www.eecis.udel.edu/~mills/ntp/html/kernpps.html
Kernel model for precision timekeeping: https://www.eecis.udel.edu/~mills/ntp/html/kern.html

[ghost]

Closed as there appears to be no appetite for the requested changes.

[by]

Nicely solved via https://www-kiokoman-eu-org.translate.goog/index.php/8-default/31-howto-raspberry-pi-4-build-kernel-for-ntp?_x_tr_sl=auto&_x_tr_tl=en&_x_tr_hl=de

[Martin-HiPi]

This is the current work-around, but it doesn't solve the issue. Every time a new kernel is released, it has to be recompiled with non-default options by external intervention.

Having the ability to enable those settings via command-line or config file would make it possible to set and forget. The newly released kernel would pick up the settings automatically.

Martin