[ntp:questions] Re: NTP sync on a standalone network (Windows 2k)

David Woolley david at djwhome.demon.co.uk
Sat Aug 19 11:37:16 UTC 2006


in article <44e634ea$0$32462$626a54ce at news.free.fr>,
Alexandre Carrausse <alex_s_p_a_m at carrausse.com> wrote:

> Let me ask the question in a different way : is the NTP protocol running 
> without any problem over a 64 kbps, or is there any configuration to think 
> about, that would tell the remote "hold on mate, don't be too impatient 
> because I am sending my packets over a 64 kbps line". I have seen somewhere 
> that it could be necessary to implement the huff'n'puff option. Is it true?

33k is quite possible.  In fact slow links can be more reliable, because, if
they overload, the round trip time goes so high that ntpd ignores the
updates until the overload goes away.

The main problem happens on systems with medium fast connections and consumer
type traffic profiles (i.e. most traffic is extracting information from the
web, and it tends to peak drastically at lunch times).  It will also depend
on how heavily utilised your link is.

In your case, I might be more worried that the encryption may be introducing
delays and uncertainties.

You can tell if you have a problem by monitoring the delay value in the 
peers subcommand of ntpq.  The best solution is to configure the routers
to give priority to NTP traffic.  This is an option that you probably have
but people dependant on an ISP generally don't have.

> OK. So it means that if someone change the time on the main server (+/-1000s 
> ie approx 20 mins) the NTP daemon will stop to provide time, and all the 

As others have said, this is really a social engineering problem.

However, the master server will continue to provide time, because
the effect of using the local clock is that their time always seems
to be perfectly correct.  It is the clients that will commit suicide.
If you are lucky, NT will still retain the last frequency correction,
and you should have an error which could be as low as 30 seconds a year.
(This is what happens on modern Unix-like systems, with kernel support
for NTP and I think that the NT time adjustment mechanism would require
ntpd to explicitly cancel its adjustment for that not to happen.)

> machine on the network will start to drift appart?... until someone realise 
> that the NTPDaemon is not started.

Given that you say that the application will crash if there is an error
of more than 3 minutes, it seems to me that it won't take long for them
to discover that one of the machines (the master) is out by more than
20 minutes.  More generally, if you cannot realise and correct this
quickly, I think you ought to look into that, rather than whether or not
the remote systems will start to free run and may fail a some time in the
future .  Similarly, if the operators are allowed to make such a mistake
and correct it, without logging the fact, you have a discipline problem.




More information about the questions mailing list