Per,
Folks have heard my sermons about avoiding per-driver PPS code on
several occasions. You apparently have joined the theocracy. Trouble is,
the implementors are infidels.
Now, that I admint is not a fair statement. The problem has to do with
grooming the PPS and competing offsets from the radio and other sources.
Most devices that produce a PPS signal in consort with a serial timecode
have quite low jitter on the timecode and it agrees fairly well with the
PPS, so the selection algorithm can construct meaningful correctness
intervals. The NMEA conventions apparently require only the that
timecode be in the same second before (after?) the PPS signal.
I don't have a NMEA device hooked up at the moment and my roof
attachments are already claimed by other antennas. I understand the NMEA
timecode has much larger jitter and the discrepancy between it tnd the
PPS is a considerable fraction of a second. Keeping a tight bound on the
allowable difference between the timecode and the PPS serves a valuable
purpose, as sometimes the timecode goes north and the PPS south. Indeed,
a couple of my radios have been doing that from time to time.
There is an easy fix for this using the tos mindist command, which sets
the correcntess interval padding, normally 5 milliseconds. Make it
something a little more than the expected maximum jitter/discrepancy of
the timecode and all should be well. If there is a systematic offset of
the timecode, a fudge should be used to reduce this.
There is a downside to this. In the present design the padding is
applied to all correctness intervals, so would affect the selection
algorithm for all servers; what is needed here is a per-driver padding.
There is in fact a way for the driver to specify this in pp->disp along
with the jitter in the refclockproc structure. So, drivers can do what
they need, perfaps with a fudge.
Dave
Per Hedeland wrote:
In article <[EMAIL PROTECTED]> "David J
Taylor"
<[EMAIL PROTECTED]>
writes:
Per Hedeland wrote:
In article <[EMAIL PROTECTED]> "David J
Taylor"
<[EMAIL PROTECTED]>
writes:
Many thanks, Harlan. I'll look into this, although I am a little
disappointed to find that less than 24 hours after starting with
FreeBSD I'm having to recompile the kernel!
Well, using PPS_SYNC shouldn't be *required* to use the PPS signal on
FreeBSD - what it does is make the kernel discipline the local clock
directly from the PPS signal, but FreeBSD also supports the PPSAPI, to
let ntpd collect the timestamps from the PPS signal. It should be
possible to use this via the ATOM driver. I haven't personally
verified any of this though (hence the "should"s) - and I guess
PPS_SYNC may give better results, but it could be interesting to try
both variants.
Per, thanks for that. I think I understand what you are saying (although
I may not next week!):
- you need to recompile the kernel if you want the PPS signal to
discipline the local clock directly
- there is an alternative programming interface, the PPSAPI, which FreeBSD
supports, but this API is not used by the NEMA driver. (Why not?)
Actually, checking the source, the NMEA driver (along with a handful of
others) *does* use the PPSAPI interface. However for these drivers it
happens sort of "under the cover", i.e. they effectively replace the
timestamp obtained from the serial data input with the one obtained from
the PPS signal, and the "core ntpd" knows nothing about it.
I've never really seen the point of this - it saves a line in the config
file, but that's about it, and it seems to me that you get less control
and monitoring capabilities than when explicitly using ATOM (actually it
has been renamed to the more appropriate PPS, I'm just behind the
times...) to collect the PPS time stamps. As far as I know you can't
even tell that you're receiving any PPS pulses other than implicitly by
the low jitter.
There is obviously also a lot of code duplication, and each driver seems
to provide its own way (if any) to tweak the PPSAPI parameters
(ASSERT/CLEAR etc) - and of course, the fact that only some of the
reference clock drivers have the PPSAPI support, and that you may need
to check the source to find out about it, doesn't help (it *is*
documented for NMEA though).
Anyway, bottom line: You were probably already using the PPS signal
before you recompiled the kernel - you just couldn't tell.:-)
--Per Hedeland
[EMAIL PROTECTED]
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
