How to configure NTP on Oracle Linux 5 Guest vServers to more quickly re-sync with NTP following a reboot
Last updated on MAY 10, 2018
Applies to:Oracle Exalogic Elastic Cloud Software - Version 220.127.116.11.0 and later
Information in this document applies to any platform.
This document identifies a configuration for the Network Time Protocol (NTP) for a guest vServer created from an Oracle Linux 5 (OL5) Exalogic Guest Base Template (EGBT) which, following a reboot of the guest, will more readily revert the system time for the guest to the NTP time that it was synchronized with prior to shutdown and restart.
After a restart the system time for a Guest vServer whose system time is synchronized with NTP can, for a period of ~11 minutes or so, change significantly relative to the system time immediately prior to shutdown.
The time shift is most likely to be of significance when the compute node where the vServer is starting has not been restarted for a considerable period and the hardware clock (hwclock) on that vServer has suffered from considerable drift away from the NTP time. This is due to the fact that the NTP time of a compute node is only synchronized back to the hwclock by executing "hwclock --systohc", which is only run automatically when the compute node itself is shutdown).
After being restarted on a compute node with it's default NTP configuration, a guest vServer will initially set it's system time from the hardware clock of the underlying Dom0, which can result in the system time either jumping forward or backward by a significant amount.
Over time, after the NTP service has started, the system time will re-synchronize with the time provided by the reachable NTP servers listed in the /etc/ntp.conf file. However, if NTP detects that the current system time is significantly different to the time received from an NTP server it elects to address the large time difference more cautiously/gradually. NTP does this by following an incremental approach, making multiple smaller adjustments over time (an ~11 minute period) rather than applying the full change all at once.
Such conditions (large drift between system time and hwclock time) are likely when a compute node hasn't been rebooted for a considerable period of time such that the hwclock has not been re-synched to the NTP time following a shutdown) and when these conditions exist on a compute node guest vServers started on that node will likely see a significant different in their initial system time set from the Dom0 hwclock, which NTP will adjust only incrementally.
The revised NTP configuration provided here will result in the NTP configuration preferring to initially set the system time available from an NTP server as a one-time change regardless of how far adrift the system time is from the NTP time received.
Sign In with your My Oracle Support account
Don't have a My Oracle Support account? Click to get started
My Oracle Support provides customers with access to over a
Million Knowledge Articles and hundreds of Community platforms