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