Hello, what you describe is not the situation I have in mind.
You describe a "lost sync" of one of the 2 Stratum 0. This is not a falseticker situation. This would lead to a "lost sync" or a "sync to local host" which will be transferred up down on the whole NTP tree, recognized by the clients and this NTP path will be ignored. Everything is clean everything is fine. And everything could be easily monitored (a lost sync is an error message!) What I describe is a falsetiker as for example: suppose that the DCF signal gives you the correct time, the GPS signal has a failure (it steps apart a bit but not soo much that NTP refuses to stay sync) and DOES give you a time BUT a wrong one. This is less easy to monitor since there no error! Both Stratum 1 will keep being sync with the respective Stratum 0 because they DO receive a time and this time is not soooo wrong to stop syncing (is not a huge jump ... say is a slow drift). The Stratum 2 will receive time from the Stratum 1. Will see that both are syncing with a Stratum 0 i.e. in principle they are both trustable but their time is too far apart to assume that both are correct. This means NTP has to decide which one is the wrong one. In this case NTP would decide which one gives the wrong time i.e. to be rejected as server with a voting criterion. The problem is that a voting criterion works only with up to 3 (well 4) servers. With 2 servers it does not work (no majority reach!). So NTP is forced to take anyway a decision but without enough elements at hand to know which is the right decision to take i.e. the decision it will take is not necessarily the correct one. Here my question. Say the decision taken is wrong. I realize it in some way (no matter how) and I want to correct it. I.e. I want to force NTP to switch from: remote refid ======================= *10.1.1.1 .GPS. x10.1.1.2 .DCF. 127.127.1.1 .LOCL. to remote refid ======================= x10.1.1.1 .GPS. *10.1.1.2 .DCF. 127.127.1.1 .LOCL. from the command line without having to change the ntp.conf file. Is it possible?? How?? Thanks. Catia Externe Mail : [email protected] 18.02.2009 10:11 Gesendet von: [email protected] An: [email protected] Kopie: Thema: Re: [ntp:questions] handling falseticker 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 _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
