[ntp:questions] Re: Problems configuring an NTP subnet

David Woolley david at djwhome.demon.co.uk
Sat May 27 09:34:56 UTC 2006


In article <T1148593641 at djhome.demon.co.uk>,
david at djwhome.demon.co.uk (David Woolley) wrote:
> In article <BDFDAB2025B27243A23D23693C576E7F542105 at CEPSAEX01.CEPSACORP.ES>,
> carlos.simo at eess.madrid.cepsa.es (SimoTerradillos, Carlos Joaquin) wrote:

Some clarification:
> > server 127.127.1.0
>   ? really needed ?

Configuring a local clock is never needed for ntpd to maintain frequency
correction after the loss of all synchronisation sources, so is of no
benefit at all for leaf nodes.

It can be of benefit for intermediate nodes, and for servers that are
obtaining time by non-NTP means, but should only be used when its effect
is clearly understood.  In particular, it is essential that there is no
ambiguity as to which local clock source to use in a sub-network at any
one time.

> fudge 127.127.1.0 stratum 5
                            ! (normally >= 10)

Because a server will appear to be synchronised accurately even though it
has never been synchronised, or was last synchronised a very long time ago
(also, ntpd on a server with a non-ntpd synchronisation source will not
know if that source has failed), it is very important that no-one uses
a system with a local clock if they have access to a proper source of
synchronisation.  Setting the local clock stratum to 10 or more makes it
very difficult for anything with some access to a real source of time
to select it and also means that the distance the time can propagate is
limited.

> tinker dispersion 1.000
  ???????????????????????

My original reaction was, why are you tinkering at all?  Tinkering always
puts ntpd into a semi-unsupported state and should always be explained in
any problem report.

On further investigation, a value of 1.000 is so far above the default of
000015 s/s that it pretty much guarantees that downstream systems will
ignore you.

> *EESS_NTPSRV_1   172.31.61.173    2 u   48   64  377   52.855  -495811   0.008
                                                                 !!!!!!!

495 seconds is almost halfway to the level of error at which ntpd will abort!
In a default configuration, this will be transient, as ntpd will step as soon
as it feels confident in its offset measurement, in which case you should have
allowed the system to stabilise before looking at how downstream systems
were behaving.

> version="ntpd 4.1.1 at 1.786 Tue Jan 28 15:20:29 CET 2003 (1)",
                  ! old                             !!!!

The 4.2.0 sources that I used for the documentation are themselves getting
a bit old.  This is older.

> stratum=3, precision=-17, rootdelay=60.590, rootdispersion=705358.888,
                                                             !!!!!!!!!! (>1,000)

If I remember correctly, a root dispersion of more than 1,000 is a reject
condition.  My original thought was that you were using a W32Time system
as your "NTP" server, but I don't think you would have synchronised at all.
However, I now think this is the result of your tinker command.

> offset=-494949.280, frequency=-500.000, jitter=0.011,
         !!!!!!!!!!!            !!!!!!!! (end stop!)

This is the high offset again, but it also shows that a maximum frequency
correction has been applied.  Either your system clock is completely broken,
or you've failed to tell us that you've selected some form of slew only 
option.  I'm not sure whether systems that are in slew only mode signal
(presumably with root dispersion) to downstream nodes that their time is
broken.

Note, as your clock is fast, this is not a case of lost interrupts.




More information about the questions mailing list