[BBLISA] ntp question

[Daniel Hagerty]

>      remote           refid      st t when poll reach   delay   offset  jitter
> ==============================================================================
> *LOCAL(0)        .LOCL.          10 l   10   64  377    0.000    0.000   0.001
>  NetworkServices .INIT.          16 u    - 1024    0    0.000    0.000   0.000
>
> and on the other:
>      remote           refid      st t when poll reach   delay   offset  jitter
> ==============================================================================
>  NetworkServices .STEP.          16 u   81 1024  366    0.807  -73.003 309.922
> *LOCAL(0)        .LOCL.          10 l    4   64  377    0.000    0.000   0.001

The important thing this is telling you is that each machine is
getting its time from "LOCAL", which is a *fake* reference clock that
uses the local clock.  No synchronization exists.

In general, use of the LOCAL reference clock is an error.  Legitimate
uses are rare.  You probably aren't one of the intended use cases.

Random commentary on different unquoted thread bits:

Try to avoid using ntpdate as a "fix time slegehammer".  A general
property you want to preserve with the system clock is monotonic
growth, where it's not possible for a second call for a timestamp to
return a time that is before the one returned by the first call for a
timestamp.  Ntpdate offers many opportunity to violate this.  Ntpd
tries to avoid it if at all possible.

In the "you're just supposed to know this" department, ntpdate is
deprecated.  See ntpd -x.  AFAIK, it's not actually a drop in
replacement and is missing things ntpdate does.  Regardless, the
ntpdate code base hasn't been maintained in a long time.  Pick your
pain.

RefIDs are either IPv4 peers/servers, something I haven't bothered to
figure out for IPv6 peers/servers, and an arbitrary, driver supplied 4
character string for a reference clock.  The driver supplied refid can
be overridden by the sysadmin to be anything.  The NTP source code is
the only place I know of where the default refclock IDs are written
down.

The NTP reach field is a byte-wide shift register, displayed in octal,
least signifigant bit being the most recent poll attempt.  So it's
really only talking about reachability over the poll interval times
eight.  Use ntpdc -c "showpeer $host"'s originate and receive
timestamps to get an idea of when a host was last successfully talked
to.  A date in 2036 means "never".

Your ntp server may have monitor support compiled in.  If it does,
"ntpdc -c system" will mention "monitor" in the system flags, and
"ntpdc -c monlist" will dump yet another table with peers, servers,
clients and some more useful communication stats.