147 lines
7.8 KiB
Plaintext
147 lines
7.8 KiB
Plaintext
This file is the original README, and is a little out of date. It
|
|
is also very specific to UofT, since there was a time when the daemon
|
|
was only run here.
|
|
|
|
To run this:
|
|
|
|
(1) Fix your kernel's value of tickadj. Tickadj sets both the
|
|
precision with which time slews can be performed and the amount
|
|
of slew you can do in a given interval. Xntpd operates by making
|
|
a bunch of little adjustments. Make tickadj too large (the default
|
|
value almost always is) and xntpd will perform poorly since the
|
|
slews will disappear in the roundoff. Make tickadj too small
|
|
and large slews won't complete before the next adjustment is
|
|
ready.
|
|
|
|
To determine a good value of tickadj to use, first determine your
|
|
kernel's value of hz (50 on a Sun 3, 100 on Sun 4's and vaxes).
|
|
Divide that number into 500 (i.e. compute 500/hz) and use an
|
|
integer near there as tickadj (say, 10 on Sun 3's, 5 on Sun 4's
|
|
and vaxes). Then adb your kernel and write the new value. You
|
|
should probably do both the running kernel and the disk image.
|
|
|
|
If your machine doesn't come with adb, or if the kernel is of a
|
|
non-Berkeley flavour, take a look at the util directory, particularly
|
|
util/tickadj.
|
|
|
|
(2) Edit the Config file in this directory. You *must* tell it whether
|
|
your machine uses big endian or little endian byte order. Also,
|
|
Suns running SunOS 3.x require special consideration, as well as Vaxes
|
|
running Ultrix 2.0 and compilers which don't understand `signed char'
|
|
declarations. When you've got all this worked out, type `make makefiles'
|
|
to distribute configuration information to Makefiles for individual
|
|
programs, followed by `make' to compile everything.
|
|
|
|
(2a) Note that, among other things, two programs were made in the authstuff
|
|
directory, authcert and authspeed. The last two are utilities for
|
|
checking the authentication code. Type `authcert < certdata'. If
|
|
this provokes a massive failure you probably got the byte order wrong
|
|
in the Config file. Type `authspeed -n 10000 auth.samplekeys', or
|
|
something, a couple of times to get a value of authdelay to stick in
|
|
the configuration file. The numbers for machines I've tried look like:
|
|
|
|
uVax II 0.001450
|
|
Sun 3/180 0.000620
|
|
uVax III 0.000515
|
|
Sun 3/60 0.000455
|
|
IBM RT Mdl 125 0.000323
|
|
Sun 3/280 0.000302
|
|
Sun 4/280 0.000110
|
|
MIPS M/1000 0.000100
|
|
|
|
(3) Typing `make install' will nstall xntpd, xntpdc, ntpdate and ntpq. Watch
|
|
the install location in the Config file.
|
|
|
|
(4) If you will be running xntpd (see 4a below for the alternative),
|
|
configure it (configuration is necessary for all machines now, though
|
|
this restriction will go away when I get broadcast time fully tested).
|
|
xntpd reads its configuration from /etc/ntp.conf (by default) and
|
|
you must tell it which machines it is to get its time from in
|
|
here.
|
|
|
|
Note that NTP operates in a hierarchy. Machines with radio clocks
|
|
(which are stratum 1 servers) are at the top of the heap, in that
|
|
all time originates with them. The situation with servers locally
|
|
is in a state of flux. We currently have one semi-reliable stratum 1
|
|
server on campus (suzuki.ccie), and maintain three other stratum 2
|
|
servers which (gently) access other people's off-campus stratum 1
|
|
servers. All of these machines are lightly loaded and have good
|
|
quality clocks, and so will probably do until we get some more stratum 1
|
|
weight.
|
|
|
|
Thus you are probably faced with choosing whether your hosts should
|
|
be stratum 2 or stratum 3 (or stratum 3 or 4 when suzuki's clock is down).
|
|
The rule of thumb is to make your best clocks and/or your file servers
|
|
stratum 2 (or 3) by peering them with the four campus servers, and make
|
|
lesser clocks and clients stratum 3 (or 4) by peering them with near
|
|
by servers which are synchonized to the campus servers. The second rule
|
|
of thumb is that more servers are better. It is quite possible to
|
|
synchronize with just a single server, but if you do your xtnpd daemon
|
|
won't have any cross checks to tell it when the server has gone
|
|
wonky. 3 or 4 lower stratum peers is about right. Note that while
|
|
you can also peer with same-stratum peers, you shouldn't do this
|
|
unless the same-stratum peer is exchanging time with a lower stratum
|
|
peer you don't talk to directly.
|
|
|
|
Anyway, for your stratum 2 servers you can probably use ntp.conf
|
|
from the conf directory directly. You will have to handcraft the
|
|
peer assocations for your stratum 3 servers.
|
|
|
|
Oh, and a note about the drift file (see ntp.conf). One of the
|
|
things xntpd does is accumulate a correction for the frequency of
|
|
the crystal in your computer. It usually takes a day or so of
|
|
running to figure this out, after which the value will usually remain
|
|
pretty stable, especially if the computer is in a machine room. The
|
|
value is printed in your syslog file (once a minute, currently, though
|
|
this will change), and can be obtained from the daemon using xntpdc.
|
|
|
|
To avoid having to wait a day after restarts before the computer
|
|
synchronizes really well, xntpd will optionally write its current
|
|
value of the frequency correction into a file, once an hour. When
|
|
it is killed and restarted, xntpd reinitializes itself to this
|
|
value on start up. This is an advantageous feature, so a driftfile
|
|
line should always be included in the configuration file.
|
|
|
|
(4a) Xntpd is a daemon. It will keep your time exquisitely precise under
|
|
normal conditions (it is quite capable of keeping a good clock within
|
|
a millisecond of a good server. Our servers aren't normally this
|
|
good, yet, but may become so when we get a few more stable local
|
|
stratum 1 peers). Even when cut off entirely from its servers xntpd
|
|
will prevent your clock from drifting seriously by continuing to apply
|
|
its accumulated frequency correction. The cost of this is that xntpd
|
|
will permanently consume memory while it is running, and real memory
|
|
at that since xntpd is unlikely to ever swap out. This cost is
|
|
currently over 100 kb.
|
|
|
|
If you aren't too worried about millisecond timing and feel religious
|
|
about keeping memory consumption at a minimum (perhaps on memory-poor
|
|
workstations), a passable alternative might be to run ntpdate instead.
|
|
Ntpdate is the NTP equivalent of rdate, a one shot date setting
|
|
program, and implements the same multiple sample/multiple server
|
|
filter algorithms as xntpd. Ntpdate was explicitly designed to be
|
|
run repeatly from cron, though it also makes a good boot time date
|
|
setter. Running ntpdate from cron on an hourly basis will keep all
|
|
but seriously broken clocks within 100 ms of on-time, and for most
|
|
clocks will probably do better than 50 ms. If this is an attractive
|
|
alternative see the manual page. You should choose ntpdate's servers
|
|
as you would the peer associations for a stratum 3 xntpd server.
|
|
|
|
(5) Once everything is configured, start the daemon(s). ntpq can be
|
|
used to see what xntpd is doing. It runs both interactive and from
|
|
the command line, type ? to see the interactive commands and ? command
|
|
to see what a command does. The `peers' command is a good one. ntpq
|
|
can also be used to see what other peoples' servers are doing, in
|
|
particular the fuzzball primary servers.
|
|
|
|
(6) If you want to use the authentication facility (this might be useful
|
|
if, for example, you were running Kerberos since this prevents people
|
|
from setting your time back and doing replay attacks on the server),
|
|
you might find a couple of useful programs in the auth_stuff directory.
|
|
mkrandkeys will generate some very random keys to use. keyparity
|
|
generates odd parity bits for keys (needed for the key file) and will
|
|
convert between key formats.
|
|
|
|
All bug reports gratefully received.
|
|
|
|
Dennis
|