> On 03/01/2025 6:06 AM PST Hal Murray via devel <devel@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. _______________________________________________ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
