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. _______________________________________________ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
