Re: [ntp:questions] basic questions about the leapsecond
Unruh wrote: As in my previous post, my ntp (4.2.4p4) running with a local shm refclock which gives it the PPS from my Garmin 18LVC, a remote level 1 source, and a remote level 2 sever, has tai=0 but has the leap flag set ( certainly not from my Garmin receiver). Of course I did NOT have the leapseconds file installed when I started ntpd. So it seems the leap flag has been received from the upstream NTP server. As I've already mentioned earlier I think ntpd should generate a log message by default (not only if explicitely configured) when it receives a leap second announcement, and from which source the announcement is received. I assume that there is some special sentences other than the NMEA sentences which the Meinberg gps receiver uses to deliver the leap second warning. Maybe. I'm not too familiar with NMEA since the Meinberg GPS clocks mostly use a different time string format which is compatible with our DCF77 receivers, which have already been existing before the first GPS clocks became available. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Meinberg PPS signal is not synchronous with refclock signal
Hi, alkope...@googlemail.com wrote: Hi I have 2 ntp servers running Linux with LinuxPPS patch. Number one uses a Meinberg PCI511 v1.00 as time source, number two uses a Meinberg GPS170PCI v1.10. On both machines ntp is configured to use the Meinberg refclock (127.127.8.0) and furthermore the Meinberg PPS outputs are connected to the serial interfaces and use the atom driver (127.127.22.0). The strange thing is, that there is always a delay of 1-4 ms between the refclock and the pps signal. In my opinion they should arrive at the exact same time. The PCI511 card decodes the AM signal from DCF77 only. Due to the characteristics of the AM signal the accuracy of the PCI511 card is only in the range of a few milliseconds, while the GPS card provides an accuracy better than 1 microsecond. So what you observe is not an NTP problem but just due to the limited accuracy of the PCI511 card which is sufficient for many standard applications. However, if you really want high accuracy you should rely on a GPS time source. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] basic questions about the leapsecond
Unruh wrote: David Woolley da...@ex.djwhome.demon.co.uk.invalid writes: David L. Mills wrote: mitigation algorithms, generally three candidates. If a reference clock is among them, only its leap bits are used. If not, a vote is taken Surely that needs to be limited to reference clocks that are definitely capable of reporting leap seconds without manual intervention, and considering the hardware, as well as the driver. It also seems to be wrong for 4.2.4p4. I have an shm PPS source, which certainly does not report leap seconds. But my system is reporting that it is leap second ready and that could only have come from its other two servers, which are not refclock drivers, but standard network servers. Again, what Dave has pointed out refers only to the dev version. 4.2.4p4 is a stable version which behaves differently. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] basic questions about the leapsecond
Antonio M. Moreiras wrote: So, if I understand, I have to: 1 - download ftp://time.nist.gov/pub/leap-seconds.3427142400 2 - rename the file to ntp.leapseconds and put it in /etc 3 - stop and start ntpd 4 - verify the warning bits As Unruh has already mentioned, only if you use the dev version. Otherwise you should do what is described under the link I've posted earlier. Maybe you should tell us which version(s) of NTP you are running. It should be done at primary servers and the others would get automatically the file if using autokey. Even if they don't use autokey the others would receive the leap second warning via the leap bits in the standard protocol. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Meinberg PPS signal is not synchronous with refclock signal
On Dec 18, 10:08 am, Martin Burnicki martin.burni...@meinberg.de wrote: Hi, The PCI511 card decodes the AM signal from DCF77 only. Due to the characteristics of the AM signal the accuracy of the PCI511 card is only in the range of a few milliseconds, while the GPS card provides an accuracy better than 1 microsecond. Hi, you got me wrong. I did not wonder about the offset between gps and pps but about the offset between gps refclock and it's own gps pps (same for dcf refclock and it's own dcf pps). Take a look at this picture: http://img-up.net/img/gps-delay0tHm49.png ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Meinberg PPS signal is not synchronous with refclock signal
On Dec 18, 12:47 pm, alkope...@googlemail.com alkope...@googlemail.com wrote: I did not wonder about the offset between gps and pps Should be: I did not wonder about the offset between gps and dcf :-) ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Meinberg PPS signal is not synchronous with refclock signal
On Dec 17, 6:57 pm, ober...@es.net (Kevin Oberman) wrote: The time to process the time string from the clock is long and fairly slow. The PPS is short and fast. As the documentation states, the PPS signal trains the clock. OK, my first example has an error. Of course I need the same fudge at the pps like at the refclock. As you say it needs time to process the time string from the refclock. This makes sense to me. So the time string comes a bit to late which should result in a negative offset to the pps signal. This is the case for my dcf server: remote refid st t when poll reach delay offset jitter == LOCAL(0).LOCL. 12 l5 64 3770.000 0.000 0.015 +GENERIC(0) .DCFi. 0 l1 16 3770.000 -0.569 0.687 oPPS(0) .PPS.0 l 14 16 3770.000 -0.003 0.797 The time for processing the time string would be ca. 0.56 ms. But on my gps server it's different: remote refid st t when poll reach delay offset jitter == LOCAL(0).LOCL. 12 l- 64 3770.000 0.000 0.015 +GENERIC(0) .GPSi. 0 l 10 16 3770.000 1.727 0.015 oPPS(0) .PPS.0 l 11 16 3770.000 -0.009 0.015 Here the reclock has a positive offset of ca. 1.72 ms. This means the time string was processed faster than the pps signal? ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
[ntp:questions] Strange jitter values
Hi One of my ntp servers (moni0) uses another ntp server (gps) as time source. The gps server gets it's time by gps ;-) As you can see in this graph the offset is quite constant: http://img-up.net/img/gps-jitter0PsFiy.png But I wonder why it shows such big jitter values? I thought jitter is only a change in the offset. As you can see in the next graph the gps servers is really close to it's pps source, too: http://img-up.net/img/gps-ppscj7qT6DN.png BTW: Why shows the last graph a constant jitter value of 0.015 ms all the time? ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] basic questions about the leapsecond
Hi there Antonio M. Moreiras wrote: Cut 1 - download ftp://time.nist.gov/pub/leap-seconds.3427142400 Is there an other source? This site appears to be down. Cut Regards, Rob ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] how to write a reference clock driver
Hello, Harlan Stenn schrieb: In article 4948f81b$0$29004$9b622...@news.freenet.de, Juergen Kosel juergen.ko...@freenet.de writes: And I also don't understand what you mean by computing time is a concern. Is the overhead of a subroutine call that significant in your application? it would be a waste of computing time to convert the reference clock time into the format guessed year, month day, hour, ... to call the subroutine refclock_process(), which would convert it back. Greetings Juergen ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Regarding Leap second adjustments
vasanth, Configure a server with local clock driver. Download the NIST leapseconds file. Set the server time shortly before the leap. Synchronize the client to the server. Watch what happens. Dave vasanth raonaik wrote: Hello Hackers, I am doing research on leap second adjustments in NTP. I would like to simulate the scenario with two machines one acting as ntp server and other as ntp client. server should send a leap second adjustment notification to client and I would like to record the steps the client takes with this notification. Could any one please let me know where i can hard code in server to send the LS (leap second bit set) to send to client. I am new to NTP please provide some pointers for understanding. Thanks, Vasanth ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] basic questions about the leapsecond
Maybe. I'm not too familiar with NMEA since the Meinberg GPS clocks mostly use a different time string format which is compatible with our DCF77 receivers, which have already been existing before the first GPS clocks became available. I haven't been able to find any NMEA documentation that describes a future leap second. The ZDA sentence does tell you the offset between GPS time and UTC. By watching that you could tell when a leap second had just happened, but then it's too late to do anything. -- These are my opinions, not necessarily my employer's. I hate spam. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] basic questions about the leapsecond
1 - download ftp://time.nist.gov/pub/leap-seconds.3427142400 Is there an other source? This site appears to be down. That site is unlikely to be down for long. Are you behind a NAT box? I need to use the passive mode for ftp. -- These are my opinions, not necessarily my employer's. I hate spam. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] basic questions about the leapsecond
Martin, The current version sends a message to the system log, protostats log and trap (if configured) when the leap is armed, disarmged or executed. Dave Martin Burnicki wrote: Unruh wrote: As in my previous post, my ntp (4.2.4p4) running with a local shm refclock which gives it the PPS from my Garmin 18LVC, a remote level 1 source, and a remote level 2 sever, has tai=0 but has the leap flag set ( certainly not from my Garmin receiver). Of course I did NOT have the leapseconds file installed when I started ntpd. So it seems the leap flag has been received from the upstream NTP server. As I've already mentioned earlier I think ntpd should generate a log message by default (not only if explicitely configured) when it receives a leap second announcement, and from which source the announcement is received. I assume that there is some special sentences other than the NMEA sentences which the Meinberg gps receiver uses to deliver the leap second warning. Maybe. I'm not too familiar with NMEA since the Meinberg GPS clocks mostly use a different time string format which is compatible with our DCF77 receivers, which have already been existing before the first GPS clocks became available. Martin ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] basic questions about the leapsecond
Rob, I am told the file is on all NTP servers operated by NIST. See the list of public servers at NIST or www.ntp.org. Dave Rob van der Putten wrote: Hi there Antonio M. Moreiras wrote: Cut 1 - download ftp://time.nist.gov/pub/leap-seconds.3427142400 Is there an other source? This site appears to be down. Cut Regards, Rob ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Meinberg PPS signal is not synchronous with refclock signal
alkope...@googlemail.com alkope...@googlemail.com writes: On Dec 18, 10:08=A0am, Martin Burnicki martin.burni...@meinberg.de wrote: Hi, The PCI511 card decodes the AM signal from DCF77 only. Due to the characteristics of the AM signal the accuracy of the PCI511 card is only = in the range of a few milliseconds, while the GPS card provides an accuracy better than 1 microsecond. Hi, you got me wrong. I did not wonder about the offset between gps and pps but about the offset between gps refclock and it's own gps pps (same for dcf refclock and it's own dcf pps). Take a look at this picture: http://img-up.net/img/gps-delay0tHm49.png That your gps report is slow is not surprizing. It is delivered in a manner that takes time to deliver. That you PPS has an offset of 20-40usec does surprize me. It should be much better than that (2-4ms is more typical) ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] how to write a reference clock driver
Juergen Kosel juergen.ko...@freenet.de writes: Hello, Harlan Stenn schrieb: In article 4948f81b$0$29004$9b622...@news.freenet.de, Juergen Kosel juergen.ko...@freenet.de writes: And I also don't understand what you mean by computing time is a concern. Is the overhead of a subroutine call that significant in your application? it would be a waste of computing time to convert the reference clock time into the format guessed year, month day, hour, ... to call the subroutine refclock_process(), which would convert it back. Oh dear. The time taken is about 1 ns on amodern CPU. Instead you waste seconds and possibly hours drinking your coffee and chatting to friends while you r computer waits for you, and you are worried about ns in order to make an orderly API for the refclocks. Greetings Juergen ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] nmea patch
On Dec 17, 11:03 pm, David Woolley da...@ex.djwhome.demon.co.uk.invalid wrote: Hal Murray wrote: In article 0ea640c4-6e30-457a-8b80-6274ea367...@k36g2000pri.googlegroups.com, dhavey dha...@gmail.com writes: and it segfaults. Any clues? Does /dev/gps0 exist? Often, it's a symlink to whatever your OS uses for /dev/tty stuff. What is that OS and what does the debugger say was the location of the crash when you run an unstripped version? Can you reproduce with an unoptimised full debug build? /dev/gps0 - /dev/pps0 exists. dmesg says: ntpd[11347]: segfault at 0 ip 003361a341ca sp 7fff3b8ca680 error 4 in libc-2.5.so[3361a0+14a000] Where is the ntp log? What full debug? Okay chill, I'm going to read the README ;) ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
[ntp:questions] NTP Leap Seconds Indicator
I have a question about the leap seconds indicator. Based on my understanding of ntp, and the html page on your site dealing with leap seconds, http://www.cis.udel.edu/~mills/leap.html, I have been telling my team that the leap second indicator was the only true arbiter of whether a mode 4 reply packet was in the leap second or the subsequent second. Therefore, we had to ensure that the value was cleared on the rising edge of the first second of the day following the insertion/deletion. So, we set up tests and I defined a control sample which was a linux box running stock ntp distribution, v4.2@1.1502-o. A little old but we haven't leapt in a while. The test setup involved a GPS simulator with a leap second scheduled which broadcast to one of our stratum 1 boxes. The stratum 1 was verified to be propagating the leap insertion bit. The control box was synchronized to the stratum 1 and propagating the leap insertion bit. Note that there was no autokey enabled. We noted that the control box did not clear the leap bit until the next poll update after the leap event. Do you believe this is the correct behavior? Is this behavior different for the latest dev tree code? Greg Dowd gdowd at symmetricom dot com (antispam format) Symmetricom, Inc. www.symmetricom.com Everything should be made as simple as possible, but no simpler Albert Einstein ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] nmea patch
On Dec 17, 11:03 pm, David Woolley da...@ex.djwhome.demon.co.uk.invalid wrote: Hal Murray wrote: In article 0ea640c4-6e30-457a-8b80-6274ea367...@k36g2000pri.googlegroups.com, dhavey dha...@gmail.com writes: and it segfaults. Any clues? Does /dev/gps0 exist? Often, it's a symlink to whatever your OS uses for /dev/tty stuff. What is that OS and what does the debugger say was the location of the crash when you run an unstripped version? Can you reproduce with an unoptimised full debug build? I think this is what you meant: /usr/local/bin/ntpd -d -l /var/log/ntpd.log -c /etc/ntp.gps ntpd 4.2@1.1541-o Thu Dec 18 21:21:02 UTC 2008 (2) addto_syslog: logging to file /var/log/ntpd.log addto_syslog: logging to file /var/log/ntpd.log addto_syslog: precision = 1.000 usec addto_syslog: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16 addto_syslog: Listening on interface #0 wildcard, 0.0.0.0#123 Disabled addto_syslog: Listening on interface #1 wildcard, ::#123 Disabled addto_syslog: Listening on interface #2 lo, ::1#123 Enabled addto_syslog: Listening on interface #3 eth0, fe80::21d: 9ff:fe18:815#123 Enabled addto_syslog: Listening on interface #4 lo, 127.0.0.1#123 Enabled addto_syslog: Listening on interface #5 eth0, 192.168.0.29#123 Enabled local_clock: time 0 offset 0.00 freq 0.000 state 0 addto_syslog: kernel time sync status 0040 addto_syslog: configure: keyword ning unknown, line ignored peer_crypto_clear: at 0 next 0 assoc ID 5670 key_expire: at 0 peer_clear: at 0 next 1 assoc ID 5670 refid INIT newpeer: 192.168.0.29-192.168.0.26 mode 1 vers 4 poll 6 10 flags 0x1 0x1 ttl 0 key peer_crypto_clear: at 0 next 0 assoc ID 5671 key_expire: at 0 peer_clear: at 0 next 2 assoc ID 5671 refid INIT newpeer: 192.168.0.29-192.168.0.27 mode 1 vers 4 poll 6 10 flags 0x1 0x1 ttl 0 key peer_crypto_clear: at 0 next 0 assoc ID 5672 key_expire: at 0 peer_clear: at 0 next 3 assoc ID 5672 refid INIT newpeer: 192.168.0.29-192.168.0.28 mode 1 vers 4 poll 6 10 flags 0x1 0x1 ttl 0 key peer_crypto_clear: at 0 next 0 assoc ID 5673 key_expire: at 0 peer_clear: at 0 next 4 assoc ID 5673 refid INIT addto_syslog: refclock_setup fd 6 tcgetattr: Inappropriate ioctl for device Segmentation fault ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] nmea patch
On Dec 17, 11:03 pm, David Woolley da...@ex.djwhome.demon.co.uk.invalid wrote: Hal Murray wrote: In article 0ea640c4-6e30-457a-8b80-6274ea367...@k36g2000pri.googlegroups.com, dhavey dha...@gmail.com writes: and it segfaults. Any clues? Does /dev/gps0 exist? Often, it's a symlink to whatever your OS uses for /dev/tty stuff. What is that OS and what does the debugger say was the location of the crash when you run an unstripped version? Can you reproduce with an unoptimised full debug build? It's centos with kernel version 2.6.27.3 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] nmea patch
On Dec 18, 11:47 am, dhavey dha...@gmail.com wrote: On Dec 17, 11:03 pm, David Woolley da...@ex.djwhome.demon.co.uk.invalid wrote: Hal Murray wrote: In article 0ea640c4-6e30-457a-8b80-6274ea367...@k36g2000pri.googlegroups.com, dhavey dha...@gmail.com writes: and it segfaults. Any clues? Does /dev/gps0 exist? Often, it's a symlink to whatever your OS uses for /dev/tty stuff. What is that OS and what does the debugger say was the location of the crash when you run an unstripped version? Can you reproduce with an unoptimised full debug build? /dev/gps0 - /dev/pps0 exists. dmesg says: ntpd[11347]: segfault at 0 ip 003361a341ca sp 7fff3b8ca680 error 4 in libc-2.5.so[3361a0+14a000] Where is the ntp log? What full debug? Okay chill, I'm going to read the README ;) ntp.log 18 Dec 13:11:16 ntpd[11838]: logging to file /var/log/ntpd.log 18 Dec 13:11:16 ntpd[11838]: precision = 1.000 usec 18 Dec 13:11:16 ntpd[11838]: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16 18 Dec 13:11:16 ntpd[11838]: Listening on interface #0 wildcard, 0.0.0.0#123 Disabled 18 Dec 13:11:16 ntpd[11838]: Listening on interface #1 wildcard, ::#123 Disabled 18 Dec 13:11:16 ntpd[11838]: Listening on interface #2 lo, ::1#123 Enabled 18 Dec 13:11:16 ntpd[11838]: Listening on interface #3 eth0, fe80::21d: 9ff:fe18:815#123 Enabled 18 Dec 13:11:16 ntpd[11838]: Listening on interface #4 lo, 127.0.0.1#123 Enabled 18 Dec 13:11:16 ntpd[11838]: Listening on interface #5 eth0, 192.168.0.29#123 Enabled 18 Dec 13:11:16 ntpd[11838]: kernel time sync status 0040 18 Dec 13:11:16 ntpd[11838]: configure: keyword ning unknown, line ignored 18 Dec 13:11:16 ntpd[11838]: refclock_setup fd 6 tcgetattr: Inappropriate ioctl for device gdb looks like this: (gdb) run -l /var/log/ntpd.log -c /etc/ntp.gps Starting program: /usr/local/bin/ntpd -l /var/log/ntpd.log -c /etc/ ntp.gps [Detaching after fork from child process 11958. (Try `set detach-on- fork off'.)] Program exited normally. (gdb) I took the -o2 flag out of the Makefile. I don't know what you mean by an unstripped version. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] nmea patch
Okay here it is ;)
What does all of that mean?
I'll try to get it out of daemon mode and then post the output from
gdb ;)
[r...@user4 ntp-4.2.4p5]# /usr/local/bin/ntpd -d -d -d -d -d -d -d -d -
d -d -l /var/log/ntpd.log -c /etc/ntp.gps
ntpd 4.2@1.1541-o Thu Dec 18 21:21:02 UTC 2008 (2)
addto_syslog: logging to file /var/log/ntpd.log
addto_syslog: logging to file /var/log/ntpd.log
adding new filegen
adding new filegen
adding new filegen
adding new filegen
adding new filegen
adding new filegen
addto_syslog: set_process_priority: Leave priority alone:
priority_done is 2
addto_syslog: precision = 1.000 usec
create_sockets(123)
addto_syslog: ntp_io: estimated max descriptors: 1024, initial socket
boundary: 16
setsockopt SO_TIMESTAMP enabled on fd 16 address 0.0.0.0
bind() fd 16, family 2, port 123, addr 0.0.0.0, flags=0x89
flags for fd 16: 0x802
Searching for addr 0.0.0.0 in list of addresses - NOT FOUND
Added addr 0.0.0.0 to list of addresses
addto_syslog: Listening on interface #0 wildcard, 0.0.0.0#123 Disabled
setsockopt SO_TIMESTAMP enabled on fd 17 address ::
bind() fd 17, family 10, port 123, addr ::, flags=0x81
flags for fd 17: 0x802
Searching for addr :: in list of addresses - NOT FOUND
Added addr :: to list of addresses
addto_syslog: Listening on interface #1 wildcard, ::#123 Disabled
update_interfaces(123)
address_okay: listen Virtual: 1, IF name: lo
address_okay: loopback - OK
examining interface #0: fd=-1, bfd=-1, name=lo, flags=0x5, scope=1,
ifindex=0, sin=::1, Enabled:
Dumping interface: 0x7fffe48d6bb0
fd = -1
bfd = -1
sin = ::1,
0a7b 0001 0100
bcast = 0.0.0.0,
mask = :::::::,
0a7b
name = lo
flags = 0x0005
last_ttl = 0
addr_refid =
num_mcast = 0
received = 0
sent = 0
notsent = 0
ifindex = 0
scopeid = 1
peercnt = 0
phase = 1
Searching for addr ::1 in list of addresses - NOT FOUND
create_interface(::1#123)
set SO_REUSEADDR to ON on ::
set SO_REUSEADDR to OFF on ::
setsockopt SO_TIMESTAMP enabled on fd 18 address ::1
bind() fd 18, family 10, port 123, addr ::1, flags=0x5
flags for fd 18: 0x802
addto_syslog: Listening on interface #2 lo, ::1#123 Enabled
Searching for addr ::1 in list of addresses - NOT FOUND
Added addr ::1 to list of addresses
created interface #2: fd=18, bfd=-1, name=lo, flags=0x5, scope=1,
ifindex=0, sin=::1, Enabled:
Dumping interface: 0x65ac70
fd = 18
bfd = -1
sin = ::1,
0a7b 0001 0100
bcast = 0.0.0.0,
mask = :::::::,
0a7b
name = lo
flags = 0x0005
last_ttl = 0
addr_refid = c84d40cf
num_mcast = 0
received = 0
sent = 0
notsent = 0
ifindex = 0
scopeid = 1
peercnt = 0
phase = 1
updating interface #2: fd=18, bfd=-1, name=lo, flags=0x5, scope=1,
ifindex=0, sin=::1, Enabled: new - created
Dumping interface: 0x65ac70
fd = 18
bfd = -1
sin = ::1,
0a7b 0001 0100
bcast = 0.0.0.0,
mask = :::::::,
0a7b
name = lo
flags = 0x0005
last_ttl = 0
addr_refid = c84d40cf
num_mcast = 0
received = 0
sent = 0
notsent = 0
ifindex = 0
scopeid = 1
peercnt = 0
phase = 1
address_okay: listen Virtual: 1, IF name: eth0
address_okay: OK
examining interface #0: fd=-1, bfd=-1, name=eth0, flags=0x11, scope=2,
ifindex=0, sin=fe80::21d:9ff:fe18:815, Enabled:
Dumping interface: 0x7fffe48d6bb0
fd = -1
bfd = -1
sin = fe80::21d:9ff:fe18:815,
0a7b fe80 021d09ff fe180815 0200
bcast = 0.0.0.0,
mask = :::::,
0a7b
name = eth0
flags = 0x0011
last_ttl = 0
addr_refid =
num_mcast = 0
received = 0
sent = 0
notsent = 0
ifindex = 0
scopeid = 2
peercnt = 0
phase = 1
Searching for addr fe80::21d:9ff:fe18:815 in list of addresses - NOT
FOUND
create_interface(fe80::21d:9ff:fe18:815#123)
set SO_REUSEADDR to ON on ::
set SO_REUSEADDR to OFF on ::
setsockopt SO_TIMESTAMP enabled on fd 19 address fe80::21d:
9ff:fe18:815
bind() fd 19, family 10, port 123, addr fe80::21d:9ff:fe18:815,
flags=0x11
flags for fd 19: 0x802
addto_syslog: Listening on interface #3 eth0, fe80::21d:
9ff:fe18:815#123 Enabled
Searching for addr fe80::21d:9ff:fe18:815 in list of addresses - NOT
FOUND
Added addr fe80::21d:9ff:fe18:815 to list of addresses
created interface #3: fd=19, bfd=-1, name=eth0, flags=0x11, scope=2,
ifindex=0, sin=fe80::21d:9ff:fe18:815,
Re: [ntp:questions] nmea patch
dhavey wrote: What full debug? Depends on your development toolset, but for gcc, it means including the -g flag and not doing anything that would strip the binary. For gcc, unoptimised means something like -O0 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] nmea patch
On Dec 18, 1:49 pm, David Woolley da...@ex.djwhome.demon.co.uk.invalid wrote: dhavey wrote: What full debug? Depends on your development toolset, but for gcc, it means including the -g flag and not doing anything that would strip the binary. For gcc, unoptimised means something like -O0 Like that? (gdb) run -l /var/log/ntpd.log -d -c /etc/ntp.gps Starting program: /usr/local/bin/ntpd -l /var/log/ntpd.log -d -c /etc/ ntp.gps ntpd 4.2@1.1541-o Thu Dec 18 21:21:02 UTC 2008 (2) addto_syslog: logging to file /var/log/ntpd.log addto_syslog: logging to file /var/log/ntpd.log addto_syslog: precision = 1.000 usec addto_syslog: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16 addto_syslog: Listening on interface #0 wildcard, 0.0.0.0#123 Disabled addto_syslog: Listening on interface #1 wildcard, ::#123 Disabled addto_syslog: Listening on interface #2 lo, ::1#123 Enabled addto_syslog: Listening on interface #3 eth0, fe80::21d: 9ff:fe18:815#123 Enabled addto_syslog: Listening on interface #4 lo, 127.0.0.1#123 Enabled addto_syslog: Listening on interface #5 eth0, 192.168.0.29#123 Enabled local_clock: time 0 offset 0.00 freq 0.000 state 0 addto_syslog: kernel time sync status 0040 addto_syslog: configure: keyword ning unknown, line ignored peer_crypto_clear: at 0 next 0 assoc ID 59506 key_expire: at 0 peer_clear: at 0 next 1 assoc ID 59506 refid INIT newpeer: 192.168.0.29-192.168.0.26 mode 1 vers 4 poll 6 10 flags 0x1 0x1 ttl 0 key peer_crypto_clear: at 0 next 0 assoc ID 59507 key_expire: at 0 peer_clear: at 0 next 2 assoc ID 59507 refid INIT newpeer: 192.168.0.29-192.168.0.27 mode 1 vers 4 poll 6 10 flags 0x1 0x1 ttl 0 key peer_crypto_clear: at 0 next 0 assoc ID 59508 key_expire: at 0 peer_clear: at 0 next 3 assoc ID 59508 refid INIT newpeer: 192.168.0.29-192.168.0.28 mode 1 vers 4 poll 6 10 flags 0x1 0x1 ttl 0 key Breakpoint 1, 0x003361a341ca in strtoll_l_internal () from / lib64/libc.so.6 (gdb) backtrace #0 0x003361a341ca in strtoll_l_internal () from /lib64/ libc.so.6 #1 0x00407c79 in getconfig (argc=value optimized out, argv=0x4) at /usr/include/stdlib.h:336 #2 0x0040c90b in ntpdmain (argc=0, argv=value optimized out) at ntpd.c:846 #3 0x003361a1d8b4 in __libc_start_main () from /lib64/libc.so.6 #4 0x00404a79 in _start () (gdb) ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] nmea patch
On Dec 18, 1:49 pm, David Woolley da...@ex.djwhome.demon.co.uk.invalid wrote: dhavey wrote: What full debug? Depends on your development toolset, but for gcc, it means including the -g flag and not doing anything that would strip the binary. For gcc, unoptimised means something like -O0 Like that? (gdb) run -l /var/log/ntpd.log -d -c /etc/ntp.gps Starting program: /usr/local/bin/ntpd -l /var/log/ntpd.log -d -c /etc/ ntp.gps ntpd 4.2@1.1541-o Thu Dec 18 21:21:02 UTC 2008 (2) addto_syslog: logging to file /var/log/ntpd.log addto_syslog: logging to file /var/log/ntpd.log addto_syslog: precision = 1.000 usec addto_syslog: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16 addto_syslog: Listening on interface #0 wildcard, 0.0.0.0#123 Disabled addto_syslog: Listening on interface #1 wildcard, ::#123 Disabled addto_syslog: Listening on interface #2 lo, ::1#123 Enabled addto_syslog: Listening on interface #3 eth0, fe80::21d: 9ff:fe18:815#123 Enabled addto_syslog: Listening on interface #4 lo, 127.0.0.1#123 Enabled addto_syslog: Listening on interface #5 eth0, 192.168.0.29#123 Enabled local_clock: time 0 offset 0.00 freq 0.000 state 0 addto_syslog: kernel time sync status 0040 addto_syslog: configure: keyword ning unknown, line ignored peer_crypto_clear: at 0 next 0 assoc ID 59506 key_expire: at 0 peer_clear: at 0 next 1 assoc ID 59506 refid INIT newpeer: 192.168.0.29-192.168.0.26 mode 1 vers 4 poll 6 10 flags 0x1 0x1 ttl 0 key peer_crypto_clear: at 0 next 0 assoc ID 59507 key_expire: at 0 peer_clear: at 0 next 2 assoc ID 59507 refid INIT newpeer: 192.168.0.29-192.168.0.27 mode 1 vers 4 poll 6 10 flags 0x1 0x1 ttl 0 key peer_crypto_clear: at 0 next 0 assoc ID 59508 key_expire: at 0 peer_clear: at 0 next 3 assoc ID 59508 refid INIT newpeer: 192.168.0.29-192.168.0.28 mode 1 vers 4 poll 6 10 flags 0x1 0x1 ttl 0 key Breakpoint 1, 0x003361a341ca in strtoll_l_internal () from / lib64/libc.so.6 (gdb) backtrace #0 0x003361a341ca in strtoll_l_internal () from /lib64/ libc.so.6 #1 0x00407c79 in getconfig (argc=value optimized out, argv=0x4) at /usr/include/stdlib.h:336 #2 0x0040c90b in ntpdmain (argc=0, argv=value optimized out) at ntpd.c:846 #3 0x003361a1d8b4 in __libc_start_main () from /lib64/libc.so.6 #4 0x00404a79 in _start () (gdb) ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] nmea patch
dhavey wrote: gdb looks like this: (gdb) run -l /var/log/ntpd.log -c /etc/ntp.gps Starting program: /usr/local/bin/ntpd -l /var/log/ntpd.log -c /etc/ ntp.gps [Detaching after fork from child process 11958. (Try `set detach-on- fork off'.)] Program exited normally. (gdb) You've run gdb on the daemon starter process. What I intended was that you ran gdb ntpd core. on the crash dump (you may need to use ulimit -c unlimited, to ensure you get a dump). I took the -o2 flag out of the Makefile. I don't know what you mean by an unstripped version. Do not run strip when installing it. Do not run install with the -s option when installing it, or run the debugger against a version before these were run. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] nmea patch
Okay here it is ;)
What does all of that mean?
I'll try to get it out of daemon mode and then post the output from
gdb ;)
[r...@user4 ntp-4.2.4p5]# /usr/local/bin/ntpd -d -d -d -d -d -d -d -d -
d -d -l /var/log/ntpd.log -c /etc/ntp.gps
ntpd 4.2@1.1541-o Thu Dec 18 21:21:02 UTC 2008 (2)
addto_syslog: logging to file /var/log/ntpd.log
addto_syslog: logging to file /var/log/ntpd.log
adding new filegen
adding new filegen
adding new filegen
adding new filegen
adding new filegen
adding new filegen
addto_syslog: set_process_priority: Leave priority alone:
priority_done is 2
addto_syslog: precision = 1.000 usec
create_sockets(123)
addto_syslog: ntp_io: estimated max descriptors: 1024, initial socket
boundary: 16
setsockopt SO_TIMESTAMP enabled on fd 16 address 0.0.0.0
bind() fd 16, family 2, port 123, addr 0.0.0.0, flags=0x89
flags for fd 16: 0x802
Searching for addr 0.0.0.0 in list of addresses - NOT FOUND
Added addr 0.0.0.0 to list of addresses
addto_syslog: Listening on interface #0 wildcard, 0.0.0.0#123 Disabled
setsockopt SO_TIMESTAMP enabled on fd 17 address ::
bind() fd 17, family 10, port 123, addr ::, flags=0x81
flags for fd 17: 0x802
Searching for addr :: in list of addresses - NOT FOUND
Added addr :: to list of addresses
addto_syslog: Listening on interface #1 wildcard, ::#123 Disabled
update_interfaces(123)
address_okay: listen Virtual: 1, IF name: lo
address_okay: loopback - OK
examining interface #0: fd=-1, bfd=-1, name=lo, flags=0x5, scope=1,
ifindex=0, sin=::1, Enabled:
Dumping interface: 0x7fffe48d6bb0
fd = -1
bfd = -1
sin = ::1,
0a7b 0001 0100
bcast = 0.0.0.0,
mask = :::::::,
0a7b
name = lo
flags = 0x0005
last_ttl = 0
addr_refid =
num_mcast = 0
received = 0
sent = 0
notsent = 0
ifindex = 0
scopeid = 1
peercnt = 0
phase = 1
Searching for addr ::1 in list of addresses - NOT FOUND
create_interface(::1#123)
set SO_REUSEADDR to ON on ::
set SO_REUSEADDR to OFF on ::
setsockopt SO_TIMESTAMP enabled on fd 18 address ::1
bind() fd 18, family 10, port 123, addr ::1, flags=0x5
flags for fd 18: 0x802
addto_syslog: Listening on interface #2 lo, ::1#123 Enabled
Searching for addr ::1 in list of addresses - NOT FOUND
Added addr ::1 to list of addresses
created interface #2: fd=18, bfd=-1, name=lo, flags=0x5, scope=1,
ifindex=0, sin=::1, Enabled:
Dumping interface: 0x65ac70
fd = 18
bfd = -1
sin = ::1,
0a7b 0001 0100
bcast = 0.0.0.0,
mask = :::::::,
0a7b
name = lo
flags = 0x0005
last_ttl = 0
addr_refid = c84d40cf
num_mcast = 0
received = 0
sent = 0
notsent = 0
ifindex = 0
scopeid = 1
peercnt = 0
phase = 1
updating interface #2: fd=18, bfd=-1, name=lo, flags=0x5, scope=1,
ifindex=0, sin=::1, Enabled: new - created
Dumping interface: 0x65ac70
fd = 18
bfd = -1
sin = ::1,
0a7b 0001 0100
bcast = 0.0.0.0,
mask = :::::::,
0a7b
name = lo
flags = 0x0005
last_ttl = 0
addr_refid = c84d40cf
num_mcast = 0
received = 0
sent = 0
notsent = 0
ifindex = 0
scopeid = 1
peercnt = 0
phase = 1
address_okay: listen Virtual: 1, IF name: eth0
address_okay: OK
examining interface #0: fd=-1, bfd=-1, name=eth0, flags=0x11, scope=2,
ifindex=0, sin=fe80::21d:9ff:fe18:815, Enabled:
Dumping interface: 0x7fffe48d6bb0
fd = -1
bfd = -1
sin = fe80::21d:9ff:fe18:815,
0a7b fe80 021d09ff fe180815 0200
bcast = 0.0.0.0,
mask = :::::,
0a7b
name = eth0
flags = 0x0011
last_ttl = 0
addr_refid =
num_mcast = 0
received = 0
sent = 0
notsent = 0
ifindex = 0
scopeid = 2
peercnt = 0
phase = 1
Searching for addr fe80::21d:9ff:fe18:815 in list of addresses - NOT
FOUND
create_interface(fe80::21d:9ff:fe18:815#123)
set SO_REUSEADDR to ON on ::
set SO_REUSEADDR to OFF on ::
setsockopt SO_TIMESTAMP enabled on fd 19 address fe80::21d:
9ff:fe18:815
bind() fd 19, family 10, port 123, addr fe80::21d:9ff:fe18:815,
flags=0x11
flags for fd 19: 0x802
addto_syslog: Listening on interface #3 eth0, fe80::21d:
9ff:fe18:815#123 Enabled
Searching for addr fe80::21d:9ff:fe18:815 in list of addresses - NOT
FOUND
Added addr fe80::21d:9ff:fe18:815 to list of addresses
created interface #3: fd=19, bfd=-1, name=eth0, flags=0x11, scope=2,
ifindex=0, sin=fe80::21d:9ff:fe18:815,
Re: [ntp:questions] nmea patch
I ran the code in gdb and this is the stack trace. At refclock_nmea.c: 178 this code causes the crash nmea_port = atoi(strtok(NULL,:)); I am not really sure of why strtok is used on a NULL string. I assume strtok return a NULL based on the trace, and then atoi calls strtool which leads to a crash. Possibly, this is a libc64 bug, as I would expect atoi to detect a null string and not to crash. #0 0x003361a341ca in strtoll_l_internal () from /lib64/ libc.so.6 #1 0x003361a31ab2 in atoi () from /lib64/libc.so.6 #2 0x00443515 in nmea_start (unit=0, peer=0x69cb58) at refclock_nmea.c:178 #3 0x0042bb9c in refclock_newpeer (peer=0x69cb58) at ntp_refclock.c:276 #4 0x00422fab in newpeer (srcadr=0x7fff552f88a0, dstadr=0x6ef0b0, hmode=3, version=4, minpoll=4, maxpoll=10, flags=129, cast_flags=1 '\001', ttl=0, key=0) at ntp_peer.c:837 #5 0x004222ea in peer_config (srcadr=0x7fff552f88a0, dstadr=0x6ef0b0, hmode=3, version=4, minpoll=4, maxpoll=10, flags=128, ttl=0, key=0, keystr=0x4776c1 *) at ntp_peer.c:525 #6 0x0040619a in getconfig (argc=0, argv=0x7fff552f8bd8) at ntp_config.c:864 #7 0x0040f5a6 in ntpdmain (argc=0, argv=0x7fff552f8bd8) at ntpd.c:846 #8 0x0040f0ec in main (argc=4, argv=0x7fff552f8bb8) at ntpd.c: 317 (gdb) up #1 0x003361a31ab2 in atoi () from /lib64/libc.so.6 (gdb) up #2 0x00443515 in nmea_start (unit=0, peer=0x69cb58) at refclock_nmea.c:178 178 nmea_port = atoi(strtok(NULL,:)); ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] nmea patch
In article 0273857b-9ab1-4aaf-9529-c9b7eb932...@w39g2000prb.googlegroups.com, dhavey dha...@gmail.com writes: I ran the code in gdb and this is the stack trace. At refclock_nmea.c: 178 this code causes the crash nmea_port = atoi(strtok(NULL,:)); I am not really sure of why strtok is used on a NULL string. I assume strtok return a NULL based on the trace, and then atoi calls strtool which leads to a crash. Possibly, this is a libc64 bug, as I would expect atoi to detect a null string and not to crash. You are off in the pile of code that's trying to get NMEA info over the net from a deamon. That happend when it can't open /dev/gps0. -- These are my opinions, not necessarily my employer's. I hate spam. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] nmea patch
On Dec 18, 3:27 pm, hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal Murray) wrote: /dev/gps0 - /dev/pps0 exists. That looks fishy. I'd expect something like: /dev/gps0 - /dev/ttyS0 and /dev/pps0 - /dev/ttyS0 -- These are my opinions, not necessarily my employer's. I hate spam. That was it! Your a freakin genuis! Tell your boss I said that you deserve a raise! ntpq -p remote refid st t when poll reach delay offset jitter == 192.168.0.26.INIT. 16 u 13 6400.000 0.000 0.000 192.168.0.27.INIT. 16 u- 6400.000 0.000 0.000 192.168.0.28192.168.0.2 3 u 11 6411.185 -1490.8 0.001 GPS_NMEA(0) .GPS.0 l- 1600.000 0.000 0.001 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] nmea patch
18 Dec 13:11:16 ntpd[11838]: configure: keyword ning unknown, line ignored That looks fishy, but I don't know if it has anything to do with the segfault. -- These are my opinions, not necessarily my employer's. I hate spam. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
[ntp:questions] Linux and mlockall()
One thing I thought I knew about the standard NTP distribution, was that it uses the mlockall() call, when available, to prevent swapping and thus gain more repeatable latencies. However, recently I had cause to run nm on ntpd, and was surprised to note no references to mlockall(). A check with ps confirmed that ntpd was indeed no longer locked in memory. I checked the source, and it seems back in 2004 someone altered the source to suppress detection of mlockall() on Linux (my platform), citing resolver problems. I haven't seen any discussion of this on this newsgroup yet. Considering that people who object to mlockall() usage on the grounds that it prevents running stock ntpd on limited-real-memory toasters have been given the cold shoulder, four years is a long time to deprive Linux users of its benefits. Since ntpd does its resolving from a secondary process, it would seem that the problem could be avoided by moving the mlockall() call to after the intres process is forked. resolver problems probably wouldn't bite me, since I use IP addresses only in my configuration files, so that I can start ntpd before named. So it should be safe for me to hack the configure script so mlockall() is used anyway, right? Also, calling this a Linux problem is likely careless. I'd imagine the root of the incompatibility is probably in the GNU libc that is widely used with the Linux kernel. Michael Deutschmann mich...@talamasca.ocis.net ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] NTP Leap Seconds Indicator
Greg, Not true. The leap warning bit has to go away only before the end of the next day. Note the upstream leap bits have at least one day to go away as well, since they are disregarded less than 28 days before the end of the month.. Dave Greg Dowd wrote: I have a question about the leap seconds indicator. Based on my understanding of ntp, and the html page on your site dealing with leap seconds, http://www.cis.udel.edu/~mills/leap.html, I have been telling my team that the leap second indicator was the only true arbiter of whether a mode 4 reply packet was in the leap second or the subsequent second. Therefore, we had to ensure that the value was cleared on the rising edge of the first second of the day following the insertion/deletion. So, we set up tests and I defined a control sample which was a linux box running stock ntp distribution, v4.2@1.1502-o. A little old but we haven't leapt in a while. The test setup involved a GPS simulator with a leap second scheduled which broadcast to one of our stratum 1 boxes. The stratum 1 was verified to be propagating the leap insertion bit. The control box was synchronized to the stratum 1 and propagating the leap insertion bit. Note that there was no autokey enabled. We noted that the control box did not clear the leap bit until the next poll update after the leap event. Do you believe this is the correct behavior? Is this behavior different for the latest dev tree code? Greg Dowd gdowd at symmetricom dot com (antispam format) Symmetricom, Inc. www.symmetricom.com Everything should be made as simple as possible, but no simpler Albert Einstein ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] nmea patch
I'm glad it is working for you and I'd be even happier if we could figure out why the NULL string got where it did earlier, as ntpd should never drop core like that. -- Harlan Stenn st...@ntp.org http://ntpforum.isc.org - be a member! ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] nmea patch
In article ywn94p108yb7@ntp1.isc.org, Harlan Stenn st...@ntp.org writes: I'm glad it is working for you and I'd be even happier if we could figure out why the NULL string got where it did earlier, as ntpd should never drop core like that. It might be just a simple bug. The code in that area says: if ((len = readlink(device,buffer,sizeof(buffer))) == -1) return(0); buffer[len] = 0; if ((nmea_host = strtok(buffer,:)) == NULL) return(0); nmea_port = atoi(strtok(NULL,:)); The idea is that if you are using the nmead, then /dev/gps0 will be a synbilic link to someting like server:port so nmea_host will be the server and nmea_port will be the port number. My (very old) man page for strtok says: The strtok() function can be used to parse the string s into tokens. The first call to strtok() should have s as its first argument. Subsequent calls should have the first argument set to NULL. Each call returns a pointer to the next token, or NULL when no more tokens are found. A less old (but still far from new) system says: The strtok() function parses a string into a sequence of tokens. On the first call to strtok() the string to be parsed should be specified in str. In each subsequent call that should parse the same string, str should be NULL. Both say Avoid using these functions. If you do use them, note that: (blah blah...) So my guess is that either the rules have changed or there is a bug in the library code. (More likely, I don't understand something.) -- These are my opinions, not necessarily my employer's. I hate spam. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
