Subject: NTP: using PPS ?
To: None <netbsd-help@netbsd.org>
From: Danny Thomas <D.Thomas@imb.uq.edu.au>
List: netbsd-help
Date: 09/18/2000 07:08:22
while this is mainly an ntp question, I thought I'd ask here in case there
were some known wrinkles lingering after ntp4 import.

I've hooked up a GPS25 receiver to a NetBSD 1.4Y/i386 box with the bundled
ntpd 4.0.99i. The PPS signal is TTL/RS232 level-translated and fed into the
DCD line of the same serial port used for the NMEA stuff (/dev/gps0 is a
link to /dev/tty01). This version of NetBSD includes both the kernel PLL
support, and I believe the PPS API. Is there a plan to update the PPS
framework, or at least the comment in sys/timepps.h, to say it's conformant
to RFC2783 - -current still says to draft 5.

I'm using the generic nmea driver (20) but it's not clear whether it
automatically enables PPS handling. From quick code-view, this driver
doesn't seem to, cf the encore one but I could well be wrong.

Even if it did, would the pps line be useful for specifying hardpps ?
  pps /dev/gps0  assert hardpps
  server 127.127.20.0  prefer

However adding the pps line results in (ntpd -d)
  ...
  peer_clear: at 0
  refclock_open: fd 8 modem status 0x7
  refclock_ioctl: fd 8 flags 0x11
  ntpd[6382]: using kernel phase-lock loop 0041
  resolving ...
  report_event: system event 'event_restart' (0x01) status 'sync_alarm,
sync_unspec, 1 event, event_unspec' (0xc010)
  ntpd[6382]: refclock_ioctl: time_pps_kcbind failed: Bad address
  ntpd[6382]: refclock_open: fd 8 ioctl failed: Bad address
  ntpd[6382]: configuration of 127.127.20.0 failed

why is the ioctl failing?

Does the "refclock_ioctl: fd 8 flags 0x11" mean it was already opened with
LDISC_PPS (0x10) ?

I was planning to test that PPS was working by swapping 'clear' for
'assert'. I expected this to shift the time by the width of the PPS pulse
(defaults to 100ms for GPS25). Would this have been a useful test ?

cheers,
Danny Thomas


still things don't seem too bad (the offset to the local GPS tends to drift
by ca 10 microseconds, even though it's appears as 0.000 below)

     remote        refid    st t when poll reach  delay  offset  jitter
=======================================================================
 224.0.1.1       0.0.0.0    16 u    -   64    0   0.000   0.000 4000.00
*127.127.20.0    .GPS.       0 l   56   64  377   0.000   0.000   0.000
-128.250.36.2    .GPS.       1 u  105 1024  377  41.853  -7.838   3.422
+130.155.98.1    .ATOM.      1 u   36   64  377  20.208  -0.659   0.735
-138.194.21.154  .ATOM.      1 u   34   64  377  39.345  -1.719   1.829
-130.95.156.206  .ATOM.      1 u   35   64  377  76.338  -2.343   1.211
#192.189.54.65   192.189.5   3 u   56 1024  377  41.022  -4.340   0.377
#130.102.128.43  130.95.15   2 u   23   64  377   2.695   0.124   0.166
-130.102.192.56  130.155.9   2 u    2   64  377   7.542   0.832   0.693
+130.102.2.15    138.194.2   2 u   53   64  356   3.152  -0.378   0.252
 130.102.2.14    130.102.4   2 u   51   64  336   3.109  -1.141   0.357
 130.102.54.74   128.250.3   2 u  157  512  367   6.167  -0.743   0.438
#130.102.4.16    150.203.1   3 u  508 1024  377   1.450   1.288   0.021
 130.102.4.10    130.102.2   3 u   37   64  372   0.607  -0.911   0.052