[ntp:questions] Re: PPS working or not? FreeBSD 5.4

Per Hedeland per at hedeland.org
Tue Jan 31 01:11:35 UTC 2006

In article <ywn93bj5b69c.fsf at ntp1.isc.org> Harlan Stenn
<stenn at ntp.isc.org> writes:
>>>> In article <drm5um$2r1h$1 at hedeland.org>, per at hedeland.org (Per
>Hedeland) writes:
>Per> I've never really seen the point of this - it saves a line in the
>Per> config file, but that's about it, and it seems to me that you get less
>Per> control and monitoring capabilities than when explicitly using ATOM
>Per> (actually it has been renamed to the more appropriate PPS, I'm just
>Per> behind the times...) to collect the PPS time stamps. As far as I know
>Per> you can't even tell that you're receiving any PPS pulses other than
>Per> implicitly by the low jitter.
>You can check out the status bits from the specific association using ntpq,
>and that does seem to be a bit lame.

Hm, I can't see that the NMEA driver does anything with status bits
depending on whether it receives PPS pulses or not - it basically boils
down to:

         * If the PPSAPI is working, rather use its timestamps.
         * assume that the PPS occurs on the second so blow any msec
        if (nmea_pps(up, &rd_tmp) == 1) {
                pp->lastrec = up->tstamp = rd_tmp;
                pp->nsec = 0;

Care to elaborate?

>Per> Anyway, bottom line: You were probably already using the PPS signal
>Per> before you recompiled the kernel - you just couldn't tell.:-)
>From what I can tell, the answer is "perhaps".  The association status bits
>would be the way to tell, and I agree that it would be better if the
>information was a bit easier to find.

Actually, there is another bit of info in David's "before" output:

precision:            1e-006 s

- and in the NMEA driver we find:

#define PRECISION       (-9)    /* precision assumed (about 2 ms) */
#define PPS_PRECISION   (-20)   /* precision assumed (about 1 us) */

- i.e., apparently it has set PPS_PRECISION. However checking the code
carefully reveals that it will do this if PPSAPI is available and the
initialization of it succeeds - which it of course will do regardless of
whether any pulses are actually received. (But since we know from the
"after" output that pulses are actually being received, I think the
answer is "yes"...)

--Per Hedeland
per at hedeland.org

More information about the questions mailing list