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

Unruh unruh-spam at physics.ubc.ca
Sat Mar 28 03:13:12 UTC 2009


mills at udel.edu (David Mills) writes:

>Bill,

>The NTPv4 model is that the server does not prejudge what the client is 
>prepared to accept. The synchronization distance includes all credible 
>contributions to the maximum error budget, including the increase in 
>maximum error due to the frequency tolerance of the server timebase. 
>This is clearly expressed in the specification along the the expectation 
>that a client (requirement for a secondary server) that if the distance 
>eexceeds the selection threshold, the server should not be considered by 
>the selection algorithm.

>The client is free to adjust the selection threshold to fit its 
>requirements. This model apples to all sources, including the atom 
>driver. The server distance itself starts at the current value of the 
>system peer at the last selection and then increases from there, even if 
>all sources are lost. A dependent client will disregard the server when 
>the distance exceeds its selection threshold.

Ah, so the atom driver is weird in that it is not regarded as a valid
source, its associated peer is regarded as the source, and if the peer is lost, the
"distance" keeps increasing via ntp's algorithm. Thus after a while ntp
will say that the PPS source has such a large error that clients will
disregard it. That is of course bizarre, since a PPS source typically has a
far far smaller error than do any of the prefer peers. 
I think that this is again a design flaw in the atom driver, and again tips
the balance toward using something like the shm refclock driver instead of
atom. At least the shm refclock is treated like a clock in its own right
and leaves it to the user, via whatever feeds the shm, to decide how to
decide when the PPS has become unreliable. 

>I am happy to continue this discussion, but only if you read the 
>specification.

I think this is an issue of how the atom driver treats the specification,
not of the specification itself.


>Dave

>Unruh wrote:

>>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
>>>> 
>>>>
>>>>      
>>>>
>>
>>_______________________________________________
>>questions mailing list
>>questions at lists.ntp.org
>>https://lists.ntp.org/mailman/listinfo/questions
>>  
>>




More information about the questions mailing list