anchor.diff:  process by sending a `USR1` signal to the `kudu-tserver` or `kudu-master`
   process. For example:
   
  -[source,bash]
   ----
   sudo pkill -USR1 kudu-tserver
   ----
  
positive.code: -69.195.159.158  128.138.140.44   2 u    9   64    1   53.885   -0.016   0.013
  *216.218.254.202 .CDMA.           1 u    6   64    1    1.475   -0.400   0.012
  +129.250.35.250  249.224.99.213   2 u    7   64    1    1.342   -0.640   0.018
   45.76.244.193   216.239.35.4     2 u    6   64    1   17.380   -0.754   0.051
   69.89.207.199   212.215.1.157    2 u    5   64    1   57.796   -3.411   0.059
   171.66.97.126   .GPSs.           1 u    4   64    1    1.024   -0.374   0.018
   66.228.42.59    211.172.242.174  3 u    3   64    1   72.409    0.895   0.964
   91.189.89.198   17.253.34.125    2 u    2   64    1  135.195   -0.329   0.171
   162.210.111.4   216.218.254.202  2 u    1   64    1   28.570    0.693   0.306
   199.102.46.80   .GPS.            1 u    2   64    1   55.652   -0.039   0.019
   91.189.89.199   17.253.34.125    2 u    1   64    1  135.265   -0.413   0.037
  $ ntpq -nc opeers
       remote           local      st t when poll reach   delay   offset    disp
  ==============================================================================
  
negative.code: In order to provide stable time synchronization with low maximum error, follow
  these best NTP configuration best practices.
  
  *Run ntpdate prior to running NTP server.* If the offset of the local
  clock is too far from the true time, it can take a long time before the NTP
  server synchronizes the local clock, even if it's allowed to perform step
  adjustments.
  
  *In certain public cloud environments, use the highly-available NTP server
  accessible via link-local IP address or other dedicated NTP server provided
  as a service.* If your cluster is running in a public cloud environment,
  consult the cloud provider's documentation for the recommended NTP setup.
  Both AWS and GCE clouds offer dedicated highly available NTP servers accessible
  from within a cloud instance via link-local IP address.
  
  *Unless using highly-available NTP reference server accessible via link-local
  address, always configure at least four time sources for NTP server at the
  local machine.* In addition to providing redundancy in case one of time sources
  becomes unavailable, this might make the configuration more robust since the
  NTP is designed to increase its accuracy with a diversity of sources in networks
  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]
  which could cause Kudu to incorrectly measure the maximum error, resulting in
  crashes. If you experience crashes related to clock synchronization on these
  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.
  
  [[disk_space_usage]]
  == Disk Space Usage
  