Re: [ntp:questions] 0.0.0.0 in log messages, ntp v4.2.6p5
On 2014-09-25 00:23, harik...@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[1818]: 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 ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] 0.0.0.0 in log messages, ntp v4.2.6p5
On Monday, September 29, 2014 2:48:33 PM UTC+8, Hari Mahadevan wrote: > On Friday, September 26, 2014 7:12:04 PM UTC+8, Martin Burnicki wrote: > > > Hari Mahadevan wrote: > > > > > > > On Thursday, September 25, 2014 2:27:01 PM UTC+8, Hari Mahadevan wrote: > > > > > > >> On Thursday, September 25, 2014 2:23:13 PM UTC+8, Hari Mahadevan wrote: > > > > > > >> > > > > > > >>> Does anybody know why the IP address reported in NTP log messages is > > >>> always 0.0.0.0? > > > > > > > > > > > > Have you also checked if this is still the same in the current > > > > > > development version, 4.2.7p*, which is available here: > > > > > > https://support.ntp.org/bin/view/Main/SoftwareDownloads > > > > > > > > > > > > Martin > > > > > > -- > > > > > > Martin Burnicki > > > > > > > > > > > > Meinberg Funkuhren > > > > > > Bad Pyrmont > > > > > > Germany > > > > I should've mentioned this in my original post -- 4.2.7 code also has the > same pattern -- NULL is passed for peer structure pointer parameter in > report_event() calls. Update: I have opened a defect against 4.2.6 for this. Defect number 2660, opened against ntpd. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] 0.0.0.0 in log messages, ntp v4.2.6p5
On Friday, September 26, 2014 7:12:04 PM UTC+8, Martin Burnicki wrote: > Hari Mahadevan wrote: > > > On Thursday, September 25, 2014 2:27:01 PM UTC+8, Hari Mahadevan wrote: > > >> On Thursday, September 25, 2014 2:23:13 PM UTC+8, Hari Mahadevan wrote: > > >> > > >>> Does anybody know why the IP address reported in NTP log messages is > >>> always 0.0.0.0? > > > > Have you also checked if this is still the same in the current > > development version, 4.2.7p*, which is available here: > > https://support.ntp.org/bin/view/Main/SoftwareDownloads > > > > Martin > > -- > > Martin Burnicki > > > > Meinberg Funkuhren > > Bad Pyrmont > > Germany I should've mentioned this in my original post -- 4.2.7 code also has the same pattern -- NULL is passed for peer structure pointer parameter in report_event() calls. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] 0.0.0.0 in log messages, ntp v4.2.6p5
Hari Mahadevan wrote: On Thursday, September 25, 2014 2:27:01 PM UTC+8, Hari Mahadevan wrote: On Thursday, September 25, 2014 2:23:13 PM UTC+8, Hari Mahadevan wrote: Does anybody know why the IP address reported in NTP log messages is always 0.0.0.0? Have you also checked if this is still the same in the current development version, 4.2.7p*, which is available here: https://support.ntp.org/bin/view/Main/SoftwareDownloads Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] 0.0.0.0 in log messages, ntp v4.2.6p5
On Thursday, September 25, 2014 2:27:01 PM UTC+8, Hari Mahadevan wrote: > On Thursday, September 25, 2014 2:23:13 PM UTC+8, Hari Mahadevan 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[1818]: 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? > > > > > > > > > > > > TIA. > > > > > > > > > > > > Hari > > > > The source code I'm referring to is in ntpd/ntp_loopfilter.c, line number > 386. report_event is defined in ntpd/ntp_control.c, line number 2929. I modified the code replacing the NULL in report_event() call with peer local variable and it works fine. Now the clock_step log message does print the IP address of the peer that was the source of the clock sync. Anyone knows why this parameter is set to NULL, not just in this one report_event() call, but in all report_event() calls in the loopfilter function? Specifically, I want to know if it's due to potential run-time errors that can bring down the daemon. Thanks! ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] 0.0.0.0 in log messages, ntp v4.2.6p5
On Thursday, September 25, 2014 2:23:13 PM UTC+8, Hari Mahadevan 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[1818]: 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? > > > > TIA. > > > > Hari The source code I'm referring to is in ntpd/ntp_loopfilter.c, line number 386. report_event is defined in ntpd/ntp_control.c, line number 2929. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
