nmea refclock not locking to the pps
Tony Hain
tony at tndh.net
Fri Mar 10 18:54:55 UTC 2017
Gary E. Miller wrote:
> Yo Tony!
>
> I'm baffled, I have been running gpsd on IPv6 hosts for almost a decade, and
> I have never had to ask for the ipv6 option.
>
> Can you dig into this some more? Something else is going on.
IPv6 is default-on, UNLESS you follow the instructions at
http://www.catb.org/gpsd/gpsd-time-service-howto.html
because as soon as you say timeservice=yes SConstruct stops building it (and the clients) as shown in the script block I pasted in below.
>
> Also, you are mixing gpsd problems, which belong on the gpsd list. And
> ntpsec problems which belong here. Can you split off you gpsd comment
> and send that to gpsd-users?
I thought about that, but we got here because you wanted me to run gpsd instead of nmea. That is still not possible even though the ntpshmmon app shows my hacky patch is creating pps events. The need to patch gpsd clearly belongs on the gpsd-users list, but there is something about the SHM driver that should be investigated here. I know people use it, but if the interface is not as crisply defined as people think it is, there may be an oversight which allows ntpshmmon to show events while the ntpsec SHM driver fails. Maybe it is just a false-ticker issue, though you would think that the reach field would show contact if the events were being seen, even if they were later rejected. I can resend that under a different subject if that is necessary.
At this point I believe my original issue with the offset is more readily explained by an asymmetry in the stack. OWAMP (http://software.internet2.edu/owamp/) shows a consistent difference in ping times between systems on the same switch, or 1-2 local router hops away in packets originating from vs. echo'd by the FreeBSD-12 stack. That indicates the original concern is not likely to be an ntpsec issue, though there were still differences between it and 4.2.8p9 which I will get back to if the asymmetry can be resolved.
Tony
>
> I do not have FreeBSD to test, so I do not understand your ppsthread.c issue.
> Can you split that off and submit to devel at ntpsec.org. There are other
> FreeBSD people there that can help.
>
> On Thu, 9 Mar 2017 22:33:36 -0800
> "Tony Hain" <tony at tndh.net> wrote:
>
> > Following up with a patch :::
> >
> > > From: Tony Hain [mailto:tony at tndh.net]
> > > Sent: Tuesday, March 07, 2017 6:16 PM
> > > To: 'Gary E. Miller'; 'bugs at ntpsec.org'
> > > Subject: RE: nmea refclock not locking to the pps
> > >
> > > Gary E. Miller wrote:
> > > ...
> > > > > > Yo Tony!
> > ....
> > > >
> > > > The default is to build with IPv6.
> > > >
> > > > > scons didn't build cgps.
> > > >
> > > > cgps has never been an option. It is always built.
> > >
> > > This was built from the example at
> > > http://www.catb.org/gpsd/gpsd-time-service-howto.html
> > > simply changing the port speed
> > > scons timeservice=yes nmea0183=yes fixed_port_speed=4800
> > > fixed_stop_bits=1
> >
> > Turns out that scons line specifically DOES NOT build cgps or ipv6.
> > # less SConstruct
> > ...
> > if ARGUMENTS.get('timeservice'):
> > timerelated = ("gpsd", "socket_export", "ncurses", "ntp",
> > "ntpshm", "pps", "oscillator", "magic_hat") for (name, default, help)
> > in boolopts: if default is True and not ARGUMENTS.get(name) and not
> > name in timerelated: env[name] = False ...
> >
> > It is long past time that ipv6 should be considered an option, so it
> > should be on the timerelated list, and if you believe cgps should
> > always be built, then gpsdclients should be as well. At the very
> > least, the web site example needs to be updated until the options get
> > fixed in SConstruct
> >
> > Sequence I ran after the patch below...
> > scons uninstall
> > scons timeservice=yes nmea0183=yes fixed_port_speed=4800
> > fixed_stop_bits=1 gpsdclients=yes ipv6=yes scons check && scons
> > install
> >
> > ...
> > > >
> > > >
> > > > > With the 3.14 port there was a cgps, but it fails on a lib error
> > > > > if used with the 3.17 gpsd.
> > > >
> > > > Of course, the shared lib of 3.14 is not compatible with that of
> > > > 3.17.
> >
> > I didn't expect it to work, but tried it just in case the lib hadn't
> > changed.
> >
> > > >
> > ...
> >
> > I patched ppsthread.c, and I am sure this is not the correct way to do
> > this since I have not been able to follow the overall structure, but
> > it does appear to have opened the api.
> >
> > ppsthread.c -
> > ...
> > #else /* not __linux__ */
> > /*
> > * On BSDs that support RFC2783, one uses the API calls on serial
> > * port file descriptor.
> > *
> > * FIXME! need more specific than 'not linux'
> > */
> > // inserting if test for /dev/pps name
> > if (strncmp(pps_thread->devicename, "/dev/pps", 8) == 0) {
> > ret = open(pps_thread->devicename, O_RDWR);
> > } else { // existing
> >
> > (void)strlcpy(path, pps_thread->devicename, sizeof(path));
> > // cppcheck-suppress redundantAssignment
> > ret = pps_thread->devicefd;
> >
> > }
> > //
> > #endif
> > // inserting error check for non-linux (makes test in linux block
> > redundant) if ( 0 > ret ) {
> > char errbuf[BUFSIZ] = "unknown error";
> > (void)strerror_r(errno, errbuf, sizeof(errbuf));
> > pps_thread->log_hook(pps_thread, THREAD_INF,
> > "KPPS:%s running as %d/%d, cannot open %s: %s\n",
> > pps_thread->devicename,
> > getuid(), geteuid(),
> > path, errbuf);
> > return -1;
> > } else { // existing
> >
> > /* assert(ret >= 0); */
> > pps_thread->log_hook(pps_thread, THREAD_INF,
> > "KPPS:%s RFC2783 path:%s, fd is %d\n",
> > pps_thread->devicename, path,
> > ret);
> >
> > }
> > //
> > /* RFC 2783 implies the time_pps_setcap() needs priviledges * ...
> >
> > # grep KPPS /var/log/messages
> > Mar 9 20:53:59 tic gpsd[67512]: gpsd:INFO: KPPS:/dev/pps1 RFC2783
> > path:, fd is 7 Mar 9 20:53:59 tic gpsd[67512]: gpsd:INFO:
> > KPPS:/dev/pps1 pps_caps 0x1111 Mar 9 20:53:59 tic gpsd[67512]:
> > gpsd:INFO: KPPS:/dev/pps1 have PPS_CANWAIT Mar 9 20:53:59 tic
> > gpsd[67512]: gpsd:WARN: KPPS:/dev/pps1 missing PPS_CAPTURECLEAR,
> pulse
> > may be offset Mar 9 20:53:59 tic gpsd[67512]: gpsd:INFO:
> > KPPS:/dev/pps1 kernel PPS will be used Mar 9 20:53:59 tic
> > gpsd[67512]: gpsd:PROG: KPPS:/dev/pps1 gps_fd:-2 not a tty, can not
> > use TIOMCIWAIT Mar 10 04:54:00 tic gpsd[67512]: gpsd:PROG:
> > KPPS:/dev/pps1 assert 1489121640.028303412, sequence: 693997,
> > clear 0.000000000, sequence: 0 - using: assert Mar 10 04:54:00 tic
> > gpsd[67512]: gpsd:PROG: KPPS:/dev/pps1 Assert cycle:
> > 1489121640028303, duration: 0 @ 1489121640.028303412 Mar 10
> > 04:54:01 tic gpsd[67512]: gpsd:PROG: KPPS:/dev/pps1 assert
> > 1489121641.027803327, sequence: 693998, clear 0.000000000,
> > sequence: 0 - using: assert Mar 10 04:54:01 tic gpsd[67512]:
> > gpsd:PROG: KPPS:/dev/pps1 Assert cycle: 999499, duration: 0 @
> > 1489121641.027803327
> >
> >
> > I am getting log events above that the api is open, and ntpshmmon
> > shows the pps events now, but the ntpsec.conf refclock line is not
> > recognizing the shm pps device.
> >
> > # ntpshmmon
> > ntpshmmon version 1
> > # Name Seen@ Clock
> > Real L Prec sample NTP0 1489124430.611470658
> > 1489124430.412209171 1489124430.000000000 0 -20 sample NTP2
> > 1489124430.611553695 1489124428.000033371 1489124428.000000000 0 -30
> > sample NTP0 1489124431.412239685 1489124431.411282520
> > 1489124431.000000000 0 -20 sample NTP2 1489124432.001544155
> > 1489124432.000033265 1489124432.000000000 0 -30 sample NTP0
> > 1489124432.415040281 1489124432.413955830 1489124432.000000000 0 -20
> > sample NTP2 1489124433.002155059 1489124433.000033281
> > 1489124433.000000000 0 -30 sample NTP0 1489124433.411896022
> > 1489124433.411793694 1489124433.000000000 0 -20 sample NTP2
> > 1489124434.002308776 1489124434.000033212 1489124434.000000000 0 -30
> >
> > # ntpmon
> > remote refid st t when poll reach delay
> > offset jitter xSHM(0) .GPS. 0 l 2 64
> > 377 0.0000 33.9512 2.4540 SHM(1) .PPS. 0
> > l - 4 0 0.0000 0.0000 0.0000
> > *2001:470:e930:2 .PPS. 1 u 33 64 377 0.9863
> > -0.3318 0.1757 +express.tndh.ne .GPS. 1 u 39 64
> > 377 1.2442 -0.2851 1.6407 +trail.tndh.net .GPS. 1
> > u 36 64 377 1.1138 -0.2766 0.1899 ntpd ntpsec-0.9.6+536
> > 2017-02-22T20:26:50Z Last update: 2017-03-09T21:13:30
> >
> > # grep ^refclock /etc/ntp.conf
> > refclock shm unit 0 refid GPS time1 0.4429166667 refclock shm unit 1
> > refid PPS prefer minpoll 2 maxpoll 2 time1
> > 0.000000337160
> >
> >
> >
> > in the FWIW department:
> >
> > # gpsmon
> > gpsmon:ERROR: SER: device open of tcp://localhost:2947 failed: No such
> > file or directory - retrying read-only gpsmon:ERROR: SER:
> > read-only device open of tcp://localhost:2947 failed: No such file or
> > directory
> >
> > # netstat -an|grep LIS
> > tcp6 0 0 ::1.2947 *.*
> > LISTEN tcp4 0 0 127.0.0.1.2947
> > *.* LISTEN
> >
> > # gpsmon tcp://[::1]:2947
> > gpsmon: No match.
> >
> > # gpsmon tcp://127.0.0.1:2947
> > gpsmon:ERROR: SER: device open of tcp://tcp://127.0.0.1 failed: No
> > such file or directory - retrying read-only gpsmon:ERROR: SER:
> > read-only device open of tcp://tcp://127.0.0.1 failed: No such file or
> > directory
> >
> >
> >
> >
>
>
>
>
> RGDS
> GARY
> ---------------------------------------------------------------------------
> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
> gem at rellim.com Tel:+1 541 382 8588
>
> Veritas liberabit vos. -- Quid est veritas?
> "If you can’t measure it, you can’t improve it." - Lord Kelvin
More information about the bugs
mailing list