ntp config tech note
hannigan at verisign.com
Thu May 20 20:16:50 UTC 2004
That's NTPv4 isn't it?
I also prefer to use three peers vs. two. Always an odd number,
greater than 1. Assumptions can't be made about the mathematics
behind time, but in a reference model, odd numbers are better.
[Not to be confused with network timing, although the same clocks
are used to provide sources for "time" over different layer 1/2/3
From: owner-nanog at merit.edu [mailto:owner-nanog at merit.edu]On Behalf Of
Sent: Thursday, May 20, 2004 4:07 PM
To: Randy Bush
Cc: nanog at nanog.org
Subject: Re: ntp config tech note
One minor (operational! -- gasp) addition:
More modern copies of ntpd have a '-g' option that will allow
the clock to jump once at boot time.
On May 20, 2004, at 12:27 PM, Randy Bush wrote:
> sorry to take you away from discussing spam with an actual
> tech note, but twice this morning i have hit incidents where
> much needed ntp clients were blown. so, as i was gonna have
> to write it up, i figured i would bore you all with it.
> ntp config hint
> ntpd will not work if your clock is off my a few minutes.
> it just sits there forever with its finger in its ear. so,
> at boot, before you start ntpd, use ntpdate to whack your
> system's time from a friendly low-numbered strat chimer.
> do not background ntpdate with -b, because, if it is slow to
> complete, ntpd can't get the port when you try to start it
> next in the boot sequence.
> if ntpdate takes a minute and thus adds to your boot time,
> then something is wrong anyway; fix it.
> in case your dns resolver is slow, servers are in trouble,
> etc. have an entry for your ntpdate chimer in /etc/hosts.
> yes, i too hate /etc/hosts; but i have been bitten without
> this hack; named is even more fragile than ntpd.
> once ntpdate has run, then and only then, start your ntpd.
> and read all the usual advice on configuration, selection
> and solicitation of chimers with which to peer, ...
> and then, if having accurate time on this host is critical,
> cron a script which runs `ntpq -c peers` and pipes it to a
> hack which looks to be sure that one of the chimers has a
> splat in front of it. run this script hourly, and scream
> bloody hell via email if it finds problems.
> now back to your regular spam discussion. /*
> yes, spam is an important issue. but, if your local
> organization, this mailing list, ... gets swamped with
> discussions of spam, then the spammers have won.
> you have to compartmentalize it, in your organization and
> in the general net culture. that's why there are
> separate mailing lists for spam, ddos, and other net crap
> with which we have to deal.
> that's why we have more than one mailing list in the
> world, to compartmentalize so we can focus.
More information about the NANOG