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: 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).
  ----
  
  ==== Installing NTP-related Packages
  
  Kudu has been well tested to work on machines whose clock is synchronized with
  `ntpd`, the NTP server from ubiquitous NTP suite.
  
  To install `ntpd` and other NTP-related utilities, use the appropriate command
  for your operating system:
  
negative.code: with higher round-trip times and jitter.
  
  *Use the `iburst` option for faster synchronization at startup*. The `iburst`
  option instructs the NTP server (both `ntpd` and `chronyd`) to send an initial
  "burst" of time queries at startup.  This results in a faster synchronization
  of the `ntpd/chronyd` with their 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/chrony.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) for both `ntpd` and `chronyd`.
  
  [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 NTP daemon at your machine) and cease
  providing NTP service at all. If in doubt, consult the `ntp.conf` or
  `chrony.conf` manual page correspondingly.
  ====
  
  
  ==== Troubleshooting NTP Stability Problems
  
  As of Kudu 1.6.0, both `kudu-master` and `kudu-tserver` are able to continue to
  operate during a brief loss of clock synchronization. If clock synchronization
  is lost for several hours, they may crash. If `kudu-master` or `kudu-tserver`
  process 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]
  