>>> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Per Hedeland) writes:
Per> Actually, checking the source, the NMEA driver (along with a handful of Per> others) *does* use the PPSAPI interface. However for these drivers it Per> happens sort of "under the cover", i.e. they effectively replace the Per> timestamp obtained from the serial data input with the one obtained Per> from the PPS signal, and the "core ntpd" knows nothing about it. Dave as sometimes written about this, and I've invariably been too busy to do more than save his writings about this subject. I would love to see the situation "normalized" and get it better documented. 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. Per> ... 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. H _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
