During this season of giving, you can show your support for the NTP Project by making a donation to Network Time Foundation.

Locking ntpd in memory

Related Topics: NtpdProcessResidencyIssues, NTP-BUG 387

Currently, ntpd will lock itself in memory if the appropriate system calls are available.

This is generally good because it means ntpd can quickly respond to time updates.

ntp-4.2.6 and earlier

For some OSes, the amount of locked memory is currently hardcoded in ntpd.c.

This is Suboptimal.

  • AIX: reserve 32k of extra stack space (less 8 4k pages).
  • WINNT callls SetProcessWorkingSetSize() and VirtualLock(), at about 4MB(?).
  • Systems that use setrlimit() and mlockall() seem to reserve an extra 50 4k pages.
    • this seems to be too much for some *BSD systems, and not enough for some linux systems.

If the ntp.conf file contains rlimit memlock 0 then while memory will be locked, there will be no limit to how much memory is locked. This behavior is OS-specific. Some will only lock what is needed, some will lock current memory. Sometimes more memory is needed and this may or may not be allowed. But this needs to be re-examined and better documented, as there is code in ntpd.c for rlimit and then later, when ntp_config() is called, we get a value for do_memlock.

ntp-4.2.8

If the ntp.conf file contains rlimit memlock -1 then ntpd does not call mlockall().

If the ntp.conf fole contains rlimit memlock 0 then the previous behavior is done - mlockall() is called but rlimit() is not.
Topic revision: r9 - 10 Dec 2015, HarlanStenn
Copyright © by the contributing authors.Use of this website indicates your agreement with, and acceptance of, the PrivacyPolicy, the WikiDisclaimer, and the PrivateWebPolicy.