On 2025-03-03 03:31, MOESSBAUER, Felix wrote:
On Fri, 2025-02-28 at 23:23 -0600, Richard Laager wrote:On 2024-10-24 09:24, Felix Moessbauer wrote:the ntpsec service starts the ntpd binary with the option "-N|-- nice" (defined in ntpsec.default (/etc/default/ntpsec) [1]. By that, the ntpd will run with the highest possible priority, which is SCHED_FIFO, prio 99. These priorities are discouraged as this can starve kernel threads. I also don't think that it is the intention of the maintainer to let it run at such a high priority.It actually was my intention. Perhaps that was misguided. But as I understood that option, it would prioritize ntpd. Maybe that's not actually necessary for good timekeeping, though?I don't think that this is needed for good timekeeping, as the NTP itself pretty well handles all kinds of latencies. If running at a higher priority (or even under RT schedulers), it should not run at the highest possible prio. Otherwise things like PI locks do not properly work anymore (because the lock holder cannot be boosted higher than the waiter).
Can you suggest a more appropriate priority? Maybe a lower FIFO priority, or maybe a high priority regular niceness?
At least this option should made easily be configurable with an env file (or any other kind of systemd dropin). On RT systems, the RT workload should never be interrupted by NTP.I've asked on the NTPsec devel list. Perhaps someone there can provide more insight.Can you please add a link here as well. Then I'll try to involve myself there.
https://lists.ntpsec.org/pipermail/devel/2025-March/010666.html -- Richard
OpenPGP_signature.asc
Description: OpenPGP digital signature
