anchor.diff:  earlier versions of Kudu and it appears that the system's NTP configuration
   is correct, consider upgrading to Kudu 1.6.0 or later.
   
  -TIP: If using other than link-local NTP server, it may take some time for `ntpd`
  -to synchronize with one of its reference servers in case of network connectivity
  -issues. In case of a spotty network between the machine and the reference NTP
  -servers, `ntpd` may become unsynchronized with its reference NTP servers. If
  -that happens, consider finding other set of reference NTP servers: the best
  -bet is to use NTP servers in the local network or *.pool.ntp.org servers.
  +TIP: If using other than link-local NTP servers, it may take some time for the
  +NTP server running on a local machine to synchronize with one of its reference
  +servers in case of network connectivity issues. In case of a spotty network
  +between the machine and the reference NTP servers, `ntpd/chronyd` may become
  +unsynchronized with its reference NTP servers. If that happens, consider finding
  +other set of reference NTP servers: the best bet is to use NTP servers in the
  +local network or *.pool.ntp.org servers.
  +
   
   [[disk_space_usage]]
   == Disk Space Usage
  
positive.code: various NTP synchronization issues can be found found at
  link:https://www.redhat.com/en/blog/avoiding-clock-drift-vms[clock-drift]
  
  ====  Monitoring Clock Synchronization Status
  
  When the `ntp` package is installed, you can monitor the synchronization status
  of the machine's clock by running `ntptime`. For example, a system
  with a local clock that is synchronized may report:
  
negative.code: between local machine's clock and the true time, the faster the NTP server can
  synchronize the clock.
  
  When running `ntpdate`, make sure the tool reports success: check its exit
  status and output. In case of issues connecting to the NTP servers, make sure
  NTP traffic is not being blocked by a firewall (NTP generates UDP traffic on
  port 123 by default) or other network connectivity issue.
  
  Below are a few examples of configuration files for `ntpd`. By default, `ntpd`
  uses `/etc/ntp.conf` configuration file.
  
  ----
  # Use my organization's internal NTP server (server in a local network).
  server ntp1.myorg.internal iburst maxpoll 7
  # Add servers from the NTP public pool for redundancy and robustness.
  server 0.pool.ntp.org iburst maxpoll 8
  server 1.pool.ntp.org iburst maxpoll 8
  server 2.pool.ntp.org iburst maxpoll 8
  server 3.pool.ntp.org iburst maxpoll 8
  ----
  
  ----
  # AWS case: use dedicated NTP server available via link-local IP address.
  server 169.254.169.123 iburst
  ----
  
  ----
  # GCE case: use dedicated NTP server available from within cloud instance.
  server metadata.google.internal iburst
  ----
  
  Sometimes it takes too long to synchronize the machine's local clock with the
  true time even if the `ntpstat` utility reports that the NTP daemon is
  