[ntp:questions] Re: handling of falsetickers with dumb NTP clients
maarten at kittensandcats.net
Mon Sep 8 11:03:01 UTC 2003
Roger wrote in message ...
>How can I handle falsetickers if the NTP implementation in the NTP
>clients does not contain a voting algorithm (dumb client)?
Consider them SNTP clients and handle voting in a layer above them.
>I've read proposals in earlier news threads that propose an
>intermediate higher stratum NTP server (e.g. simple UNIX servers
>running nptd) that is placed in front of (or nearby) the NTP client
>and that runs the voting algorithm to identify falsetickers.
...Right. What can I say? It sounds like a good idea to me.
>I am reluctant to invest in additional NTP server equipment, as I do
>not really see the benefits yet.
>Main problem I see: what happens if this higher stratum NTP server
>itself becomes a falseticker? Then the NTP clients will get wrong
>time as well.
That's why you hang your intermediate layer very thickly connected
off your top layer.
>Basically, with a dumb client I see no chance for a reliable solution
>to cope with falsetickers, or am I wrong?
>But can additional higher stratum NTP servers provide better
>protection against falsetickers?
>As I see it, the basic question is who provides more reliable time,
>the low stratum server or an additional higher stratum server?
This depends on your low stratum server.
>Well there is probably no general answer. Maybe it depends on the
>stratum and characteristics of the servers, so lets look at my case:
>My NTP clients (some are dumb, some are intelligent ie support
>´voting´) are distributed over several sites. Nearly each site will be
>equipped with a stratum 1 server containing a GPS receiver. The
>clients shall be time synchronized to about 50ms accuracy using NTP or
>The stratum 1 NTP server characteristics are:
>The servers do not support symmetric mode, basically they are SNTP
>servers which only base time on the GPS receiver as reference. Until
>the server has been locked to the GPS reference signal, it sets LI=3
>(alarm condition, clock not synchronized), so it´s not possible to
>manually configure wrong time. When the GPS reference signal fails,
>the internal rubidium clock enters holdover mode - the clock shows
>very good holdover performance - and the server continues to answer
>NTP requests, indicating a higher value for the stratum field in the
You have stratum 1 sources with internal Rb clocks and you're
worried about falsetickers?
>A dumb NTP client will probably continue to use the local NTP server
>running in holdover mode. Intelligent clients might change over to one
>of the remote servers operating on stratum 1.
This "very good holdover performance" is goint go be _quite_ good
enough to maintain 50ms accuracy in the clients.
>Now, would it beneficial to have one (or more?) additional stratum 2
>servers on each site to vote between the local stratum 1 server and 2
>(3) remote stratum 1 servers, and to serve all local clients or at
>least the dumb clients?
If you really want to worry about these GPS+Rb gadgets going wild.
>Would such a stratum 2 server (e.g. a Solaris server running ntpd)
>provide more reliable time than the local stratum 1 server?
Only failover-wise, probably.
>Is there a difference if the site does not contain a stratum 1 NTP
>server? Maybe it is justified to put a stratum 2 server in these
There is an administration issue. You have many clients and it may
be useful to keep their configuration easy. It _might_ be a good
thing to introduce an intermediate layer of NTP servers just to
decouple the clients from the (end) servers.
More information about the questions