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
[ntp:questions] ACTS modem advice?
I'm running ntpd 4.2.6p5 on an Ubuntu 14.04.1 system (kernel version = 3.13.0-36-generic). I'm thinking of setting up the ACTS_MODEM driver to give me a backup time reference in case my GPS loses its signal. I have an old Conexant HSF modem card, which I was able to install on an old Linux box many years ago, but I can't seem to get it to work on my current system. The main company (Linuxant) that used to supply Linux drivers for this and similar cards has apparently lost interest, and all the web sites I can find that mention Conexant HSF modem cards are ancient (no updates in 4-5 years, claim Linux 2.6 or 2.4 is the latest kernel, etc.). Has anyone out there succeeded in getting a Conexant HSF modem to work with a current Linux system? If so, I'd be grateful for pointers to any up-to-date drivers and documentation. If getting this hardware to work today is a lost cause, what current Linux-compatible modem hardware would people suggest? It would be nice if a new modem could handle fax (so that I can use it for more than just occasional time service calls). Rich Wales ri...@richw.org ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] Running dual stack NTP servers in the pool
We have had a couple of NTP servers we provide to pool.ntp.org for a few years with one IPv4 address on each server. We have rolled out IPv6 access and wanted to know if we should be setting these NTP servers up as dual stack with IPv4 and IPv6. We are not sure if there is a way to show one server with both IP addresses or if should add this as a new server to list the IPv6 address. Thanks. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Atomic Signal Transmitter/Repeater???
On Monday, June 13, 2011 8:17:54 AM UTC-7, Chris Albertson wrote: .. My purpose for getting WWWV is to compare it with GPS time and I hope maybe learn something about the atmosphere. Any different in the two times must be because of the path delay. Partly solved problem: There are interesting ways to discover time delay data. All you need do is keep the GPS receiver fixed in space. Any apparent motion over time belongs to atmospheric changes. The apparent wandering of multiple GPS receivers might give additional information. GPS time is accurate and precise--- Research differential GPS. http://en.wikipedia.org/wiki/Differential_GPS; GPS assisted surveying has proven to have astounding quality and many Automobile GPS devices have a parallel receiver to collect current data and apply it. Back of the envelope GPS reacts to picosecond time signals to generate a default accuracy of 15-meter nominal accuracy and when augmented to about 10 cm in case of the best implementations. The back of my envelope demands no wire longer than 15 meters and if I am serious 10 cm (about 1.x nano seconds). All logic and amplifier delays insert additional errors and even when understood must be stable over time and temperature. Inside a single GPS receiver clock deltas can be measured in picoseconds even if the absolute time is +/- 100ns... Look hard at individual GPS receivers because many can lock on numerous signals: receiver that tracks both GPS and GLONASS satellites simultaneously. When using them together, the receiver has the ability to lock onto 24 more satellites than using GPS alone. If you can extract the raw data you can look for differential transit time data from all 24 paths. i.e. does the local location appear to move as each satellite is added to or removed from the computation. Small systems like the Raspberry Pi now have GPS add on devices inspect the device driver code to see how much you can dig out of the hardware. An old Android phone likely has GPS hardware and Android is mostly open source. ___ 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 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
