Catia, [email protected] wrote: > Hallo, > > I have the following configuration Stratum 0 configuration: > > 1 x Stratum 0 (DCF "Clock") --> 1 x Stratum 1 (let's give it the IP > 10.1.1.1) > 1 x Stratum 0 (GPS "Clock") --> 1 x Stratum 1 (let's give it the IP > 10.1.1.2) > I do not have (for security policy) the possibility to give any other > alternative (extern) time source to the Stratum 2 Servers. > > This means that my Stratum 2 Servers have only 2 servers. Obviously this > configuration is not "falseticker save". > I have a monitoring active which warns me if the time offset between the 2 > Stratum 1 server gets bigger than a fixed limit. > > In such a situation anyway the NTP daemon on the Stratum 2 servers would > mark one of the 2 Stratum 1 servers as a falseticker and "ignore" the time > coming from it. > Since there are only 2 Stratum 1 server to choose from the "voting" > decision do not really apply, in such a way that the decision that the NTP > on the Stratum 2 servers take upon "ops! there is a falseticker. Which one > is falseticker?" is rather casual (I guess). > > Say they mark the server 10.1.1.1 as falseticker. > > > remote refid > =================== > *10.1.1.1 .GPS. > x10.1.1.2 .DCF. > 127.127.1.1 .LOCL. > > At this point I will get a warning from my monitoring, I will check > manually with an external source which time really is and have a look to > the decision that NTP on the Stratum 2 Server took. Say I realize that the > decision taken is wrong: the 10.1.1.1 is not the false ticker, the true > false ticker is 10.1.1.2 > > What should I do? I mean is there a way to force NTP "on the fly" to > change it's mind? I have in mind something like a command line saying > "force to trust server 10.1.1.1" (which simultaneously automatically will > imply "then ignore 10.1.1.2 since this means it is the true > falseticker")? ==> to force the following "switch" > > remote refid > =================== > x10.1.1.1 .GPS. > *10.1.1.2 .DCF. > 127.127.1.1 .LOCL. > > Sure I could reconfigure ntp.conf with a prefer on the 10.0.0.1 server, > and restart the daemon (would it work? I guess so), but I do not really > like it, I find it to "permanent". > > > thanks
If both of your NTP servers provided a different time even though their GPS and DCF77 refclocks were synchronized then this would be a bug in the NTP server's software. In this case a client which polls both servers had no chance to find out which of the 2 upstream servers was a false ticker. The only way to resolve this automatically is to configure at least 1 more upstream server. If one of your NTP servers has lost synchronization with the incoming radio signal from GPS or DCF77 then the times received from both servers will start to drift apart slowly, depending on the accuracy of the oscillators. Depending on the configuration of the "trust time" of the refclocks in your NTP servers the root dispersion of the freewheeling server will start to increase, so NTP clients should be able to find out which of the servers provides "better" time. Alternatively you can configure the "local clock" on your NTP servers and fudge their stratum to 15. So if the GPS or DCF77 receiver has lost synchronization then (possibly after a "trust time") the NTP server will select the local clock as system peer. If the local clock's stratum is 15 then the NTP server will be seen as stratum 16 on the network, which means "not synchronized", so that NTP server will be discarded by the clients. Hope this helps. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
