[ntp:questions] handling of falsetickers with dumb NTP clients
roger.neumann at web.de
Thu Sep 4 23:00:09 UTC 2003
How can I handle falsetickers if the NTP implementation in the NTP
clients does not contain a voting algorithm (dumb client)?
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.
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.
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?
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
My preferred solution is: configure all NTP clients in a site to use
the local (i.e. in the same site) stratum 1 NTP server. This local NTP
server also should be the preferred server for each client. The
clients operate in client/server mode. Only few LAN equipment (one
L2/L3 Ethernet switch and maybe one router) is between NTP server and
For redundancy, each client also connects to one stratum 1 server in
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
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.
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?
Would such a stratum 2 server (e.g. a Solaris server running ntpd)
provide more reliable time than the local stratum 1 server?
What are the most likely causes which turn a server into a
falseticker? Software or hardware errors in the server? Software or
hardware error in the GPS receiver? Erroneous time calculation in the
GPS receiver due to shading, reflections or interferences in the
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
Many thanks for any comments or ideas.
More information about the questions