1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
|
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
|
