Re: [ntp:questions] nmea patch
In article , Harlan Stenn 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
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 http://ntpforum.isc.org - be a member! ___ 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
[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 ___ 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
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
>/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. ___ 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 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
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
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, Ena
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
On Dec 18, 1:49 pm, David Woolley 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=, argv=0x4) at /usr/include/stdlib.h:336 #2 0x0040c90b in ntpdmain (argc=0, argv=) 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 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=, argv=0x4) at /usr/include/stdlib.h:336 #2 0x0040c90b in ntpdmain (argc=0, argv=) 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: > 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
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, Ena
Re: [ntp:questions] nmea patch
On Dec 18, 11:47 am, dhavey wrote: > On Dec 17, 11:03 pm, David Woolley > > wrote: > > Hal Murray wrote: > > > In article > > > <0ea640c4-6e30-457a-8b80-6274ea367...@k36g2000pri.googlegroups.com>, > > > dhavey 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
On Dec 17, 11:03 pm, David Woolley wrote: > Hal Murray wrote: > > In article > > <0ea640c4-6e30-457a-8b80-6274ea367...@k36g2000pri.googlegroups.com>, > > dhavey 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 17, 11:03 pm, David Woolley wrote: > Hal Murray wrote: > > In article > > <0ea640c4-6e30-457a-8b80-6274ea367...@k36g2000pri.googlegroups.com>, > > dhavey 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
[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 wrote: > Hal Murray wrote: > > In article > > <0ea640c4-6e30-457a-8b80-6274ea367...@k36g2000pri.googlegroups.com>, > > dhavey 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
Re: [ntp:questions] how to write a reference clock driver
Juergen Kosel writes: >Hello, >Harlan Stenn schrieb: > In article <4948f81b$0$29004$9b622...@news.freenet.de>, Juergen Kosel > 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] Meinberg PPS signal is not synchronous with refclock signal
"alkope...@googlemail.com" writes: >On Dec 18, 10:08=A0am, Martin Burnicki >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] 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: > > > > > >>1 - download ftp://time.nist.gov/pub/leap-seconds.3427142400 >> >> > >Is there an other source? >This site appears to be down. > > > > >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] 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
>> 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
>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] 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] how to write a reference clock driver
Hello, Harlan Stenn schrieb: In article <4948f81b$0$29004$9b622...@news.freenet.de>, Juergen Kosel 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] basic questions about the leapsecond
Hi there Antonio M. Moreiras wrote: > 1 - download ftp://time.nist.gov/pub/leap-seconds.3427142400 Is there an other source? This site appears to be down. Regards, Rob ___ 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] 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
Re: [ntp:questions] Meinberg PPS signal is not synchronous with refclock signal
On Dec 18, 12:47 pm, "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 18, 10:08 am, Martin Burnicki 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] 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] basic questions about the leapsecond
Unruh wrote: > David Woolley 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] 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: > 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