> This is from: https://bugs.debian.org/1086000
> Does anyone have insight on this? Is running at real-time priority > actually helpful to timekeeping accuracy? Yes, it helps. I don't have any numbers to say how much. How often is probably more interesting. I'd be happy if we changed it to old fashioned nice. Or a lower priority. Where should we document this? > If not, I'll remove this from the Debian package (and we should probably > remove the option upstream entirely?). I hope you/Debian don't have to maintain patches. -------- 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. If they turn on usestats, they can get some numbers for CPU utilization. That gives you the total usage in the last hour. It doesn't tell you how long the longest burst was. sysstats will give you packet counts. If we are really causing a problem for Siemens, I'd really like to understand what's going on. --------- There are two critical areas for timing NTP packets. One is from packet arrival to grabbing the time stamp. That's done in the kernal so no problem for us even if we run at low priority. 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 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. In client-only mode, the CPU load is very light. This is typical for most PCs. A light server doesn't add much load. On the other hand, a busy server can chew up a lot of CPU cycles and the admin is probably happy to dedicate a whole core to ntpd. There is a related issue of locking everything into memory. -- These are my opinions. I hate spam. _______________________________________________ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
