[ntp:questions] RE: How to change STRATUM on linux.
david at djwhome.demon.co.uk
Fri Oct 20 08:53:25 UTC 2006
[ BROKEN THREAD - Missing References Line - manually repaired ]
In article <EB998357DB660742877807C9BD7D251B44526D at SRVR1.searo.local>,
philippe.dhont at searo.be (Philippe Dhont Sea-ro) wrote:
> Yes you can, and i finally found how.
I think we all know about the local clock driver as it is so commonly
included in configurations without justification and is dangerous in
> On the server, this is my ntp.org configuration:
> server 127.127.1.0
> fudge 127.127.1.0 stratum 5
Redundancy already noted. Even when this is used in disaster scenarios
with an otherwise valid time synchronisation architecture, the advice is
to set this to at least 10, so that bogus times cannot propagate too
> I also have a second one with higher stratum.
> My local clock is sync'ed with a windows2003 server like this:
> Net time -S x.x.x.x set , and put in crontab.
This is an invalid time synchronisation architecture for NTP, as the
upstream link is neither NTP nor a local hardware reference clock. It's
actually also invalid for SNTP and would still be if SNTP were used
rather than what I suspect here is SMB. (Typical Microsoft W32Time
architectures are invalid because they use SNTP as a source for SNTP,
but that is not as bad as your current one.)
The latest service pack of Windows 2003 includes a version of W32Time
that may actually be NTP architecture compliant; it is certainly much
more compliant than this architecture. Although non-compliant, using
older versions of W32Time, as though they were real NTP servers, would
still be better.
> My 2003 server is sync'ed with the daytime protocol to a internet time
This is perverse. Even the old version of W32Time would be better, as
it at least isn't limited to a one second resolution. The latest
service pack version of Windows 2003 ought to do really rather well,
although the reference implementation of ntpd, which is free, is still
better, and what we would advise. (I believe the latest W32Time is still
limited to the system tick rate as resolution, whereas the reference
> I need a good stratum value because my cisco devices (switches etc) will
> not sync if the stratum is 16.
Obviously they won't synch if the source is unsynchronised. The source
would also have been sending an alarm state in the leap bits.
So this is my cisco configuration:
> Best to put 2 time servers in cisco devices.
Two is a bad number, as, if they disagree, you can't resolve the
dispute. Having two local clocks in a system, unless one is slave
to the other, is a very bad idea.
> address ref clock st when poll reach delay offset disp
> *~x.x.x.x 127.127.1.0 6 373 1024 377 3.1 0.28 0.3
> ~x.x.x.x 127.127.1.0 8 1012 1024 377 2.4 -760.9 103.9
If it weren't being rejected on stratum, the lack of overlap in the
error bands between the second and first source would, I believe,
cause both sources to be rejected as false tickers. It's faintly
possible to have this amount of offset difference between two remote
servers, but these servers will be indicating very tight error bounds.
Unfortunately, when you use the local clock driver to propagate time
that has been synchronised by non-NTP means, it fails to send the correct
error information, although, in this case, if it had done, the Cisco should
have rejected it for having too high a root dispersion.
> So, it can be done.
We know it can be done, but we strongly advise not to do it in this way,
especially as it would seem that the choice of platforms etc. would
actually permit a fully compliant solution.
More information about the questions