NTP users are strongly urged to take immediate action to ensure that their NTP daemon is not susceptible to use in a reflected denial-of-service (DRDoS) attack. Please see the NTP Security Notice
for vulnerability and mitigation details, and the Network Time Foundation Blog
for more information. (January 2014)
ntpd Process Residency Issues
In general, it is best for
to get time packets with the smallest possible latency on the receive timestamp.
Over the years we have learned that on some (versions of some) OSes we can obtain better results with
through the use of techniques like:
- using a non-default scheduling priority
- locking the process in memory
- keeping sections of memory permanently resident
Originally, there was no ability to use any of these mechanisms to improve the performance of
. As they became available we added existence checks to
so we could use these features if they were available.
As OS technology has matured, newer kernels have developed better ways to obtain the receive timestamp, and techniques like memory locking under these kernels have new problems or unexpected consequences or behaviors.
The previous memory locking (for example) interfaces are still provided for backward compatibility, but now there are times where they should no longer be used.
- we do not need to use (any of?) these techniques to get better receive timestamps.
- Are there any other reasons to use any of these techniques?
- Yes, refclocks (other than LOCAL) have no timestamp capability, so prio/mlock is useful for them.
- So, if no refclocks (other than LOCAL) are used then there is no need for prio/mlock.
- Also, possibly even with refclocks, if kernel stream module used.
Also see: LockingNtpdInMemory