[ntp:questions] pps coming in, not received by ntpd

David Lord snews at lordynet.org
Sat Jun 29 20:21:44 UTC 2013


folkert wrote:
> Hi,
> 
> Something odd is happening.
> I've connected a garmin 18 lvc to a pc.
> The system has a kernel with pps support and i verified it comes in:
> 
> root at hoei:/home/folkert# cat /sys/devices/virtual/pps/pps0/{assert,clear}
> 1372528130.997131540#54
> 1372528131.097120120#54
> 
> I'm running gpsd and it says the gps has a fix and it also has all
> appropriate devices open:
> 
> gpsd      27762           nobody    7u      CHR               4,65 0t0       1144 /dev/ttyS1
> gpsd      27762           nobody    9r      CHR              251,0 0t0      82440 /dev/pps0
> 
> gps is started with '-n'
> 
> ntpd is configurated to listen to the shared memory segments:
> 
> server 127.127.28.0 minpoll 4
> fudge  127.127.28.0 refid NMEA
> server 127.127.28.1 minpoll 4 prefer
> fudge  127.127.28.1 refid PPS
> 
> Both nptd and gpsd look at the first 2 segments:
> 
> ------ Shared Memory Segments --------
> key        shmid      owner      perms      bytes      nattch     status      
> 0x4e545030 0          root       600        96         2                       
> 0x4e545031 32769      root       600        96         2                       
> 0x4e545032 65538      root       666        96         1                       
> 0x4e545033 98307      root       666        96         1                       
> 0x47505344 131076     root       666        8240       1                       
> 
> The PPS seems to be seen by gpsd:
> root at hoei:/home/folkert# strace -fp 27872 2>&1 | grep ioctl
> ...
> [pid 27873] ioctl(9, PPS_FETCH, 0x7f1e63cc9d00) = 0
> 
> and the NMEA sentences are processed correctly:
> 
> x127.127.28.0    .NMEA.           0 l   10   16  377    0.000  -275.55 4.421
> 
> but the pps isn't:
> 
>  127.127.28.1    .PPS.            0 l    -   16    0    0.000    0.000 0.000
> 
> Anyone any idea?

For my "Sure" gps I have:

server 127.127.20.2 mode 18 prefer
# NB the server line is "prefer"
fudge 127.127.20.2 stratum 4 time2 0.417 refid GPSb
server 127.127.22.2
fudge 127.127.22.2 flag2 0 flag3 1 refid PPSb

The time2 value was obtained by running with noselect for a
few days and taking an average from the peer_summary mean for
the GPS. That value has since been adjusted to give a mean
closer to zero.


My MSF derived refclock uses radioclkd2 and that has:

server 127.127.28.0
fudge 127.127.28.0 stratum 1 time 1 0.024000 refid MSFa

with prefer being the pps synced server.

MSF server is about same as my other systems with rms offset of
about 0.4ms vs 3us for GPS/PPS. Also note that minpoll 4 seems
to introduces an occasional spike of >> 10us so I'm back to
not having minpoll or maxpoll specified.


David

> 
> Folkert van Heusden
> 



More information about the questions mailing list