Bug#1086000: ntpsec: ntpd runs with SCHED_FIFO 99 and might starve the system

[James Browning]

> On 03/01/2025 6:06 AM PST Hal Murray via devel <devel at ntpsec.org> wrote:

> I hope you/Debian don't have to maintain patches.

They maintain some; I looked at the stack, and they are patches
for clan Debian packages. I think Fedora does the same for RPM
packaging.

> ntpd only uses one thread. (more when doing DNS lookups, but they don't
> run for long) Modern CPUs have multiple cores so this is unlikely to be a
> problem. But maybe Siemens is running on a low end SOC with only one
> core. But that would only be a problem if they also had a big blast of
> network traffic.

Doesn't NTPsec also use a thread or two to handle NTS-KE
traffic?

> The other is from the time the transmit side grabs the time until the
> packet hits the wire. With NTS, that window is a lot larger -- it can't
> do the crypto until it has put the time stamp in the packet.

There are a couple of ways around that: to interleave, and the
other is adding a pair of extensions to hold a better t4' with
the latter adjusting the UDP checksum.

> There is code in there to yield after N packets to give the other parts of
> ntpd a chance to run. We could easily add a sleep to that. But then, how
> long to sleep? I'd like to avoid that rathole.

It would depend on a few things. In an ideal world, mainly if
the SHM refclock is enabled because other i/o will joggle
select/polls elbow leaving scheduled polls/maintenance. Which
wants to occur on the second, but not every second.