[ntp:questions] 0.0.0.0 in log messages, ntp v4.2.6p5
Brian.Inglis at SystematicSw.ab.ca
Tue Sep 30 05:32:29 UTC 2014
On 2014-09-25 00:23, harikvpy at gmail.com wrote:
> Does anybody know why the IP address reported in NTP log messages is always 0.0.0.0?
> For example the message written while stepping the clock looks like this:
> Sep 25 13:03:47 ntpd: 0.0.0.0 061c 0c clock_step +340.491291 s
> I looked into ntpd source and it's always passing a NULL for report_event()'s second parameter where it should be passing the peer with which the local clock is being sync'ed. Interestingly the peer information is available, yet it's not being passed as second argument. Why?
These messages correspond to events related either to the system (algorithms), servers or peers.
System events are reported with address 0.0.0.0.
Server and peer events are reported with a non-zero address.
See "Event Messages and Status Words" decode.html.
Driver events and log messages are reported with the driver class and type name, and unit.
If you enable all log messages you will see some zero and non-zero addresses, if you have any servers or peers configured.
If you enable only system messages, you will only see 0.0.0.0.
If you are seeing a 340s clock step, your system time setting or configuration may have issues.
But that step is based on the system offset, not normally a particular driver, server, or peer.
The system peer as described below is the current best representative of the survivors contributing to the combine algorithm, but unless the mitigation rules decide otherwise, its stats alone will not normally replace the combine stats.
From "Mitigation Rules and the prefer Keyword" prefer.html:
"2. Combine Algorithm
The clock combine algorithm uses the survivor list to produce a weighted average of both offset and jitter. Absent other considerations discussed later, the combined offset is used to discipline the system clock, while the combined jitter is augmented with other components to produce the system jitter statistic inherited by dependent clients, if any.
The clock combine algorithm uses a weight factor for each survivor equal to the reciprocal of the root distance. This is normalized so that the sum of the reciprocals is equal to unity. This design favors the survivors at the smallest root distance and thus the smallest maximum error.
Ordinarily, the combining algorithm computes a weighted average of the survivor offsets to produce the final synchronization source.
The clustering algorithm ranks the truechimers first by stratum then by synchronization distance and designates the survivor with the lowest distance as the potential system peer.
Take care. Thanks, Brian Inglis
More information about the questions