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