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

David L. Mills mills at udel.edu
Tue Jan 31 02:11:29 UTC 2006


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 <8gkDf.11755$wl.3150 at text.news.blueyonder.co.uk> "David J
> Taylor"
> <david-taylor at blueyonder.co.not-this-bit.nor-this-part.uk.invalid>
> writes:
> 
>>Per Hedeland wrote:
>>
>>>In article <qObDf.11636$wl.1818 at text.news.blueyonder.co.uk> "David J
>>>Taylor"
>>><david-taylor at blueyonder.co.not-this-bit.nor-this-part.uk.invalid>
>>>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
> per at hedeland.org




More information about the questions mailing list