NTPD(8) 						 Clockwatcher's Programming Manual						   NTPD(8)

NAME

       ntpd - time synchronization daemon implementing NTP

SYNOPSIS

       ntpd [-d] [-s] [-t]

OPTIONS

       -d will bump the debug level by one.  May be specified more than once to increment debug level by one each time.  Has no effect if ntpd has
       not been compiled with DEBUG defined.

       -s will cause ntpd to not adjust the the local clock.

       -t will cause ntpd to modify the value of tickadj in your kernel.  This will have no  effect  unless  ntpd  was	compiled  with	SETTICKADJ
       defined.

DESCRIPTION

       NTPD  is  the network time synchronization daemon and is normally invoked at boot time from the /etc/rc(8) file.  It implements a new revi-
       sion of the Network Time Protocol first described in RFC-958.  It maintains the host's time synchronized with a	set  of  distributed  time
       servers,  each with varying accurracy and reliability.  Multiple time server masters may exist, but there is no requirement for election of
       a single master.

       Ntpd uses the adjtime(2) system call to slew the clock of the host by small amount in order to keep the clock synchronized.  If	the  local
       clock exceeds the ``correct'' time by some threshold, then settimeofday(2) is used to make a step adjustment of the local clock.

       When  ntpd(8)  is  started on the machine, it reads configuration information from /etc/ntp.conf which contains information about other ntp
       time servers and host specific information.  Configuration information is listed one entry per line, with fields separated  by  whitespace.
       Lines which begin with a ``#'' character are treated as comments.  Here is a sample configuration file:
	 #
	 #	   Local clock parameters
	 #
	 #    Precision of the local clock to the nearest power of 2
	 #	   ex.
	 #		60-HZ	= 2**-6
	 #		100-HZ	= 2**-7
	 #		1000-HZ = 2**-10
	 precision -7
	 #
	 # intrinsic drift of local clock
	 #
	 tickadj 1
	 #
	 #    Peers	     Type Name
	 #
	 peer	    foo.umd.edu
	 peer	    192.5.39.94
	 peer	    bar.arpa
	 server     bogon.umd.edu
	 passive    bozo.umd.edu

       There  are  two	major types of information specified in the configuration file: local host information, and remote timer server specifica-
       tion.  The local host information is used to describe the intrinsic properties of the local host's timekeeping machinary.  The commands	in
       this group are precision, and tickadj.

       The precision command takes a number which describes the resolution of the local clock, as a power of two.  For example, a VAX system typi-
       cally has a 100 HZ clock and thus a precision of -7.  If the symbol _hz is defined in the namelist of /vmunix, this value is  automatically
       set based on the value of hz.

       The  tickadj command is used to specify the granularity of clock adjustment done by the adjtime(2) system call.	If the -s option is speci-
       fied when ntpd is invoked, the kernel variable _tickadj is modified via /dev/kmem.  The preferred method of setting tickadj is by  changing
       the  value  in  the  kernel  file  conf.c instead of having ntpd set in this rude fashion.  On a VAX, a value of 1 is usually used. See the
       README file for typical values of tickadj on various hardware platforms.

       Currently three timer server specifications are supported.  They are peer, server and passive.  Each command  takes  either  a  dotted-quad
       internet  address  or  a  host name.  Each host specified in any one of the three commands is elligable to be synchronized to, while random
       hosts which set up a peer relationship are not.	The peer and server commands create an active polling situation; in the case of peer,  the
       NTP  packets  are  sourced in Symmetric-Active mode, while using server causes the packets to be in Client mode.  When reachability is lost
       with a configured host in either of these two cases, the daemon will continue to poll to re-acquire that host.  A  host	specified  in  the
       passive	command will not continue to be polled.  If that host begins to poll us, it will be eligable as to be synchronized but will not be
       polled if reachability is lost.

       It is recommended that the bulk of the peers configured should be specified with the client keyword; this will minimize resource  usage	on
       the  remote  NTP  server.  If your host will be serving as a redistribution point for a cluster of hosts,  you should set up peer relation-
       ships with higher quality clocks (lower stratums) and other equal stratum clocks.  In other words, if you are not  redistributing  time	to
       others, you shouldn't need to configure any peers in your NTP configuration; client specifications are more appropriate.

NOTES

       Please choose your NTP peers carefully; send mail to ntp@TRANTOR.UMD.EDU for assitance.

       There exists a broadcast command which will exercise completely untested code.  Use at your own risk.

       There  is  no reason to believe that the hpux code which was added still works.	In general, this code and adaptations of the NTPD to plat-
       forms without the adjtime(2) system call are not likely to be very satisfying.

BUGS

       No doubt.

FILES

       /etc/ntp.conf  NTP daemon configuration file

SEE ALSO

       adjtime(2), settimeofday(2), RFC-958, Network Time Protocol (Version 1) Specification and Implementation, Revised 17 September 1988

AUTHORS

       Louis A. Mamakos, louie@TRANTOR.UMD.EDU
       Michael G. Petry, petry@TRANTOR.UMD.EDU
       The University of Maryland, Computer Science Center.

LOCAL
								 27 November 1996							   NTPD(8)