mi...@udel.edu (David Mills) writes: >John,
>The intersection algorithm has been documented in several places along >with configuration controls to modify its behavior. Is the tyranny you >cite due to that algorithm or the notion of the prefer peer in the first >place? If the latter, do you have an alternate suggestion? Well, I would suggest that the atom driver has a flag-- a fudge or something, which would dissociate it from any prefer peer once intial lock had been obtained. Ie, itwould regard the PPS as the best time source whether any prefer peer exists or not. That way , if someone wants the current behaviour they can have it, and if they want the PPS to take precedence they can have that as well. IF you are going to have a single PPS driver, which you appear to want, then it is a good idea to make it very flexible and able to be set up to the user's desires. >Dave >John Ackermann N8UR wrote: >> >> >> David Mills said the following on 03/28/2009 11:12 PM: >> >>> John, >>> >>> The intended design to detect and suppress bad reference/PPS clocks >>> is at least two additional sources, that do not have to be reference >>> clocks. If the reference/PPS clock sails to the sunset, the selection >>> algorithm will vote it off and the PPS will follow. The server will >>> continue at whatever surving source stratum plus one. This might not >>> be considered pefect, but it would avoid real disaster. >> >> >> Dave, I fully agree with you that the PPS signal should be subject to >> the selection algorithm. It's the tyranny of the prefer peer that I >> object to. >> >> John _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions