[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: How to use ntp/ntpdate to fix my clock



On Sat, 29 Jan 2000, Ed Cogburn wrote:
> Henrique M Holschuh wrote:
> > ntpdate is used to do a "one time only" update to your clock. ntp is used to
> > discipline your clock and will in fact keep the RTC in a short leash
> > updating it every 11 minutes.
> 
> 	I don't believe ntp is what Patrick needs.  "ntp" is the daemon, i.e.

Yes, I agree. Patrick, try ntpdate first. It is much easier, and it demands
far less configuration. Read the bottom of this message for a fast server
select method and install guide.

> the server.  "ntpdate" is the "client software".  I think what Patrick

Well, ntpdate is a client-only software. ntp contains ntpd, the timekeeping
daemon, which is both a server and a client. ntpdc, ntpq and others are
client-only as well (and are included in the ntp package). But this is just
a detail anyway ;-)

> elsewhere in ntpdate or ntp-doc packages).  For most of us, we should
> access a secondary server, there is no reason for an "end-user" like
> us to be using primary servers.  I seem to remember also that some

Unless you're less than 100ms away and serving time yourself to about 100
machines, using a proper configured ntp server, you have *no* business
contacting a primary (stratum 1) time server.

Actually, an end-user should have no business contacting public stratum 2
servers either, they should use their ISP's timeservers. But not many ISPs
are this high-quality to offer timekeeping services...  At the very least
their backbone providers should have *good* ntp servers open to anyone in
their net segment (which includes the ISP users), but not even this is true.

> primary servers require "permission to access" first.  Get to that

Most secondary servers *do require permission to acess* as well. Only they
don't feel the need to packet-filter everybody else on a show of faith that
you will ask permission first. Start abusing and that won't last long.

> list, write down 3-4 of the secondary servers that are geographically
> close, and plug that info into ntpdate's config file.

*NO*.  At the very least ping them and discard the ones which are too far.

ntpdate will hammer every server you tell it about with 4 to 8 request
packets, causing "load" bursts on the server and you have no business doing
that to 3 or 4 servers just because you're too lazy to do it right.

Either use only *one* server for ntpdate, or select two (if you think two is
not enough for ntpdate, either you'd better study the ntp docs and go
install ntp instead, or you have a severely fucked up network connectivity).


Here is a possible method to doing the server selection for ntpdate:

First select a bunch (5 to 10) servers from the stratum-2 file from
www.ntp.org. Pay special attention to the "use policy", and geographic
location (actually, network location, but closer geographically _usually_
means closer network-wise). You'll notice most administrators request you to
at the very least tell them you'll be using their servers.

Now ping the servers you selected. Drop any which has average ping times
above 300ms, they won't be useful. If all of them have ping times above
300ms, select the two with the lowest packet drop ratio. Servers with ping
times above 800ms are useless.

Drop any servers which lost too many 'ping' packets, ntp/ntpdate uses UDP
and won't work well with high packet loss (actually one shoud use ntpq
instead of ping to do this right, but that requires you to understand the
ntpq output).

Get the two best servers (lowest ping time) which aren't in the same network
domain (if possible). Remember to email them request permission for usage if
their entry in the stratum-2 file tells you to do so.

Edit /etc/init.d/ntpdate and add the server(s) you selected. Remove
hwcloch --adjust calls in /etc/init.d/hwclock.sh because it will bite you
sooner or later.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh 


Reply to: