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

[Hal Murray]

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

Good catch.  Thanks.


>> 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. 

Adjusting the UDP checksum doesn't work with NTS.

Interleave requires per-client storage on the server.  I haven't seen a 
good solution to that problem area.


>> 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. 

There is nothing magic about SHM.  The solution is a thread per refclock.


-- 
These are my opinions.  I hate spam.