diff options
Diffstat (limited to 'usr.sbin/xntpd/doc/UofT')
| -rw-r--r-- | usr.sbin/xntpd/doc/UofT | 146 |
1 files changed, 146 insertions, 0 deletions
diff --git a/usr.sbin/xntpd/doc/UofT b/usr.sbin/xntpd/doc/UofT new file mode 100644 index 0000000..54420d5 --- /dev/null +++ b/usr.sbin/xntpd/doc/UofT @@ -0,0 +1,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 |
