> 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. _______________________________________________ bblisa mailing list [email protected] http://www.bblisa.org/mailman/listinfo/bblisa
