Re: handling falseticker

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 : questions-bounces+catia.lavalle=bechtle.com@xxxxxxxxxxxxx
18.02.2009 10:11


Gesendet von: questions-bounces+catia.lavalle=bechtle.com@xxxxxxxxxxxxx
An:
questions@xxxxxxxxxxxxx




Kopie:








Thema:
Re: [ntp:questions] handling falseticker






Catia,

catia.lavalle@xxxxxxxxxxx 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
.

Relevant Pages

  • Re: Setting Up NTP Subnet
    ... > I have questions regarding best practices on architecture of NTP ... > it sufficient to use multiple GPS receivers with ACTS dial backup ... me that we should create a stratum 2 tier peer layer a stratum 3 tier ... servers and that the servers at this level should peer. ...
    (comp.protocols.time.ntp)
  • Re: Setting Up NTP Subnet
    ... > I have questions regarding best practices on architecture of NTP ... > it sufficient to use multiple GPS receivers with ACTS dial ... The lower the stratum the bigger the ... servers and that the servers at this level should peer. ...
    (comp.protocols.time.ntp)
  • Re: handling falseticker
    ... You describe a "lost sync" of one of the 2 Stratum 0. ... recognized by the clients and this NTP path will be ignored. ...
    (comp.protocols.time.ntp)
  • Re: Setting Up NTP Subnet
    ... the documentation I have for a well known Stratum 1 NTP site shows ... I find it odd that one cannot NTP peer these appliances. ... servers and that the servers at this level should peer. ... *There's no relation to the cache DNS, just shared services on the same ...
    (comp.protocols.time.ntp)
  • Toggling time sync between two servers
    ... I'm new to ntp, but have been asked to debug an issue with our NTP ... fudged at stratum 0 and the other at stratum 2. ... These two processors act as the NTP servers to all other processors on ... restart min polling due to step ...
    (comp.protocols.time.ntp)