Unix/Linux Go Back    

BSD 2.11 - man page for ntpd (bsd section 8)

Linux & Unix Commands - Search Man Pages
Man Page or Keyword Search:   man
Select Man Page Set:       apropos Keyword Search (sections above)

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

       ntpd - time synchronization daemon implementing NTP

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

       -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.

       NTPD  is the network time synchronization daemon and is normally invoked at boot time from
       the /etc/rc(8) file.  It implements a new revision 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 sepa-
       rated 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	    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 specification.  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 typically has a 100 HZ clock and thus a preci-
       sion of -7.  If the symbol _hz is defined in the namelist of /vmunix, this value is  auto-
       matically 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 specified 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 pas-
       sive.  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  ran-
       dom  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  Symmet-
       ric-Active mode, while using server causes the packets to be in Client mode.  When reacha-
       bility is lost with a configured host in either of these two cases, the daemon  will  con-
       tinue  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  syn-
       chronized 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
       relationships 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 con-
       figure any peers in your NTP configuration; client specifications are more appropriate.

       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 platforms without the adjtime(2) system call  are
       not likely to be very satisfying.

       No doubt.

       /etc/ntp.conf  NTP daemon configuration file

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

       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)
Unix & Linux Commands & Man Pages : ©2000 - 2018 Unix and Linux Forums

All times are GMT -4. The time now is 09:19 AM.