anchor.diff:  between local machine's clock and the true time, the faster the NTP server can
   synchronize the clock.
   
  -When talking about the 'synchronization' with true time using NTP, we are
  -referring to a couple of things:
  -- the synchronization status of the NTP server which drives the local clock
  -  of the machine
  -- the synchronization status of the local machine's clock itself as reported
  -  by the kernel's NTP discipline
  -
  -The former can be retrieved using the `ntpstat`, `ntpq`, and `ntpdc` utilities
  -(they are included in the `ntp` package). The latter can be retrieved using the
  -`ntptime` utility (the `ntptime` utility is also a part of the `ntp` package).
  -For more information, see the manual pages of the mentioned utilities and
  -the paragraph below.
  +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
  
positive.code: with higher round-trip times and jitter.
  
  *Use the `iburst` option for faster synchronization at startup*. The `iburst`
  option instructs `ntpd` to send an initial "burst" of time queries at startup.
  This results in a faster synchronization of the `ntpd` with its reference
  servers upon startup.
  
  *If the maximum clock error goes beyond the default threshold set by Kudu
  (10 seconds), consider setting lower value for the `maxpoll` option for every
  NTP server in `ntp.conf`*. For example, consider setting the `maxpoll` to 7
  which will cause the NTP daemon to make requests to the corresponding NTP
  server at least every 128 seconds. The default maximum poll interval is 10
  (1024 seconds).
  
  [NOTE]
  ====
  If using custom `maxpoll` interval, don't set `maxpoll` too low (e.g., lower
  than 6) to avoid flooding NTP servers, especially the public ones. Otherwise
  they may blacklist the client (i.e. the `ntpd` daemon at your machine) and cease
  providing NTP service at all. If in doubt, consult the `ntp.conf` manual page.
  ====
  
  A few examples of `ntpd` configuration files:
  
  ----
  # 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
  ----
  
  TIP: After configuring `ntpd`, first run the `ntpdate` tool with the same set
  of NTP servers (it's assumed that `ntpd` is not running when the `ntpdate` tool
  is run). 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. Then start the `ntpd` daemon and use the
  `ntpq` tool described above to verify that the NTP daemon is able to connect
  to its reference servers.
  
  ==== Troubleshooting NTP Stability Problems
  
  As of Kudu 1.6.0, Kudu daemons are able to continue to operate during a brief
  loss of clock synchronization. If clock synchronization is lost for several
  hours, daemons may crash. If a daemon crashes due to clock synchronization
  issues, consult the `ERROR` log for a dump of related information which may
  help to diagnose the issue.
  
  TIP: Kudu 1.5.0 and earlier versions were less resilient to brief NTP outages. In
  addition, they contained a link:https://issues.apache.org/jira/browse/KUDU-2209[bug]
  
negative.code: Sep 17, 8:32:31.135 PM FATAL tablet_server_main.cc:38 Check failed: _s.ok() Bad status: Service unavailable: Cannot initialize clock: Cannot initialize HybridClock. Clock synchronized but error was too high (11711000 us).
  ----
  
  In this and following NTP-related paragraphs, when talking about the
  'synchronization' with true time using NTP, we are referring to a couple of
  things:
  - the synchronization status of the NTP server which drives the local clock
    of the machine
  - the synchronization status of the local machine's clock itself as reported
    by the kernel's NTP discipline
  
  The former can be retrieved using the `ntpstat`, `ntpq`, and `ntpdc` utilities
  if using `ntpd` (they are included in the `ntp` package) or the `chronyc`
  utility if using `chronyd` (that's a part of the `chrony` package). The latter
  can be retrieved using either the `ntptime` utility (the `ntptime` utility is
  also a part of the `ntp` package) or the `chronyc` utility if using `chronyd`.
  For more information, see the manual pages of the mentioned utilities and the
  paragraphs below.
  
  ==== NTP-related Packages
  For a long time, `ntpd` has been the recommended NTP server to use on Kudu
  nodes to synchronize local machines' clocks. Newer releases of Linux OS offer
  `chronyd` as an alternative to `ntpd` for network time synchronization. Both
  have been tested and proven to provide necessary functionality for clock
  synchronisation in a Kudu cluster.
  
  ===== Installing And Running `ntpd`
  `ntpd` is the NTP server from the ubiquitous `ntp` suite.
  
  To install `ntpd` and other NTP-related utilities, use the appropriate command
  for your operating system:
  