[ntp:questions] Stick to PPS, even if the prefer server fails

Unruh unruh-spam at physics.ubc.ca
Fri Mar 27 23:11:11 UTC 2009


mills at udel.edu (David Mills) writes:

>Bill and John,

>To Bill: Once upon a time several reference clock drivers I wrote had 
>their own idiosycratic PPS support. There are over forty now in the 
>driver collection. Years ago I pulled PPS support from all the drivers I 
>wrote in favor of the atom driver. Most drivers can be used with the 
>atom driver; the NMEA driver does use the $GPGSA sentence presumably to 
>police the PPS, but there is no evidence the other GPS drivers do. The 
>SHM driver you cite does much the same thing as the atom driver to 
>monitor the offset, but so far as I can see does not groom the signal 
>itself. Years ago I accidently plugged a signal generator in the PPS and 
>the kernl went nuts.

I am sure it would. However, that is not a failure mode one should be too
concerned about. However, on my GPS PPS every once in a while it will issue
10 pulses in one second. No idea what is causing this noise, but I have
seen it on two versions of the GPS18. It is certainly true that the driver
should do somethingabout this. (It does not however seem to caused any
great problem with my system running from that source via the shm driver,
perhaps because it throws away 60% of inputs over the 16 sec poll interval.


>You have a flawed interpreation of the NTP algorithms with respect to 
>the synchronization distance and selection threshold. There is no need 
>to wait for one day in seconds. That went away with NTPv4. As for a 

That was put in there only if the person wanted to allow the PPS to
freewheel but only for a limited time (one day in my example). Ie, the PPS
source is assumed to be fine for 1 day even if no prefer peer is selected.

Whether there is otehr code in teh atom driver which relies on their being
a prefer peer associated with the PPS I do not know. 

>sticky bit, that would not be hard to add once things like flag glut are 
>overcome, but from my experience here I would not recommend it for use 
>in a public server. It is not as simple as you think, as things like the 
>syncrhonization distance have to be mitigated, etc.

>To John: I suspect you know that all LORSTA stations run by the Coast 
>Guard include in the weekly announcement series a time-of-coincidence 
>(TOC) second at which the epoch of the second is equal to the epoch of 
>the GRI. My Astron LORAN-C receiver, which was modified by the Coast 
>Guard, flashes a light at the TOC. The TOCs and the intervals between 
>them vary up to several minutes depending on the GRI of the chain. I 
>made provisions for the TOC in the LORAN-C receiver I built some years 
>ago, but never completed the code to exploit them.

>Dave

>Unruh wrote:

>>jra at febo.com (John Ackermann N8UR) writes:
>>
>>  
>>
>>>David Woolley wrote:
>>>    
>>>
>>>>Unruh wrote:
>>>>
>>>>      
>>>>
>>>>>I have now looked at the refclock_atom source and indeed, it demands that a
>>>>>prefer clocksource is available, and ignores the PPS if it is not. This I
>>>>>believe is a bug, or at least a design infelicity. You could either hack
>>>>>        
>>>>>
>>>>I suspect the reasoning may be that both normally come from the same 
>>>>radio clock which will free-run the PPS when it loses a signal, so that 
>>>>detecting the failure of the NMEA data is the only way of telling that 
>>>>the PPS data is unreliable.
>>>>      
>>>>
>>
>>  
>>
>>>More than that, some PPS sources don't have an accompanying timecode, so 
>>>they need another source to provide the coarse time.  This does cause 
>>>some interesting design challenges because it makes the PPS reliant on 
>>>an external source.
>>>    
>>>
>>
>>  
>>
>>>A couple of years ago I tried defining multiple prefer peers to improve 
>>>the reliability, but never got that working in a reliable way.
>>>    
>>>
>>
>>  
>>
>>>I'd like to see one of two solutions:  (a) the ability to define 
>>>multiple prefer peers, such that failure of one would cause a switch to 
>>>another; or (b) an option that would require an external sane source for 
>>>initial sync, but once the time is known to the second, continue relying 
>>>on the PPS even if the prefer server goes away.
>>>    
>>>
>>
>>The second would be trivial to apply. Just stick in a flag which gets set
>>once the initial external source has converged to within .1 sec say, and
>>if set it stays set and the PPS source gets used if it is set. If you
>>really worry, you could augment the flag everytime the prefer peer was
>>unavailable ( resetting it every time it was) and not use PPS if that
>>counter got greater than 86400 say ( one day)  This is about a three line
>>change to the atom driver. 
>>
>>
>>
>>  
>>
>>>BTW -- this is a real-world issue, at least for my definition of 
>>>"world".  Two of my NTP servers have this problem.  One syncs from a 
>>>Cesium atomic clock, and the other from a LORAN-C receiver.  Both those 
>>>sources provide PPS but no accompanying timecode.
>>>    
>>>
>>
>>Use the shmpps code with the refclock_shm driver. It will wait until the
>>time source is reported to have an offset of less than .25 sec, and then
>>start the shm report of the PPS source. Thereafter it will continue to use
>>the PPS source as a normal source, which you can make the preferred source. 
>>
>>
>>
>>_______________________________________________
>>questions mailing list
>>questions at lists.ntp.org
>>https://lists.ntp.org/mailman/listinfo/questions
>>  
>>




More information about the questions mailing list