[ntp:questions] Fwd: Re: NetBSD GPS/PPS using 4.2.6p3

A C agcarver+ntp at acarver.net
Sat Aug 27 01:24:38 UTC 2011


On 8/26/2011 13:11, Rick Jones wrote:
> A C<agcarver+ntp at acarver.net>  wrote:
>> Let me add that I'm using only the PPS_ATOM right now (GPS_NMEA is
>> not in the ntp.conf file at all) and the 64-ish bytes of binary data
>> is showing up at the serial port once per second.
>
>> However, even with a debug level of 10 I don't show anything being
>> written to the port.
>
> If there is a user space process involved, a system call trace utility
> can be a very good friend.
>
> rick jones

Yeha, I've run ktrace on it before but it doesn't match what is being sent.

I ran it again and the PPS_ATOM driver is transmitting data at regular 
intervals:

   1327      1 ntpd     1314394905.210995629 CALL 
ioctl(6,PPS_IOC_FETCH,0xefffe584)
   1327      1 ntpd     1314394905.211100621 GIO   fd 6 wrote 28 bytes
        "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
   1327      1 ntpd     1314394905.211273608 GIO   fd 6 read 28 bytes
        "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"

   1327      1 ntpd     1314394906.211064913 CALL 
ioctl(6,PPS_IOC_FETCH,0xefffe584)
   1327      1 ntpd     1314394906.211172905 GIO   fd 6 wrote 28 bytes
        "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
   1327      1 ntpd     1314394906.211346891 GIO   fd 6 read 28 bytes
        "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"

   1327      1 ntpd     1314394907.226187042 GIO   fd 6 wrote 28 bytes
        "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
   1327      1 ntpd     1314394907.226371028 GIO   fd 6 read 28 bytes
        "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"


It's a string of nulls.  But that doesn't match what shows up at the 
port itself both in length and in data content.  But the timing is 
consistent (one write per second).  Whatever is taking the write to the 
file descriptor is then just bundling more data with it and shipping out 
a 64 byte packet of data.  64 bytes just happens to be the length of a 
NTP packet if you include the IP and UDP headers.  I tried to manually 
decode it but some fields weren't looking quite right.



More information about the questions mailing list