2 .\" $FreeBSD: src/usr.sbin/ntp/doc/ntp.conf.5,v 1.2.2.6 2003/03/11 22:31:29 trhodes Exp $
3 .\" $DragonFly: src/usr.sbin/ntp/doc/Attic/ntp.conf.5,v 1.2 2003/06/17 04:29:58 dillon Exp $
10 .Nd Network Time Protocol (NTP) daemon configuration file
16 configuration file is read at initial startup by the
18 daemon in order to specify the synchronization sources,
19 modes and other related information.
20 Usually, it is installed in the
23 but could be installed elsewhere
28 The file format is similar to other
33 character and extend to the end of the line;
34 blank lines are ignored.
35 Configuration commands consist of an initial keyword
36 followed by a list of arguments,
37 some of which may be optional, separated by whitespace.
38 Commands may not be continued over multiple lines.
39 Arguments may be host names,
40 host addresses written in numeric, dotted-quad form,
41 integers, floating point numbers (when specifying times in seconds)
44 The rest of this page describes the configuration and control options.
46 .Qq "Notes on Configuring NTP and Setting up a NTP Subnet"
48 (available as part of the HTML documentation
50 .Pa /usr/share/doc/ntp )
51 contains an extended discussion of these options.
52 In addition to the discussion of general
53 .Sx Configuration Options ,
54 there are sections describing the following supported functionality
55 and the options used to control it:
56 .Bl -bullet -offset indent
58 .Sx Authentication Support
60 .Sx Monitoring Support
62 .Sx Access Control Support
64 .Sx Reference Clock Support
67 Following these is a section describing
68 .Sx Miscellaneous Options .
69 While there is a rich set of options available,
70 the only required option is one or more
77 .Sh Configuration Support
78 Following is a description of the configuration commands in
80 These commands have the same basic functions as in NTPv3 and
81 in some cases new functions and new arguments.
83 classes of commands, configuration commands that configure a
84 persistent association with a remote server or peer or reference
85 clock, and auxiliary commands that specify environmental variables
86 that control various related operations.
87 .Ss Configuration Commands
88 The various modes are determined by the command keyword and the
89 type of the required IP address.
90 Addresses are classed by type as
91 (s) a remote server or peer (IP class A, B and C), (b) the
92 broadcast address of a local interface, (m) a multicast address (IP
93 class D), or (r) a reference clock address (127.127.x.x).
95 only those options applicable to each command are listed below.
97 of options not listed may not be caught as an error, but may result
98 in some weird and even destructive behavior.
99 .Bl -tag -width indent
100 .It Xo Ic server Ar address
101 .Op Cm key Ar key \&| Cm autokey
104 .Op Cm version Ar version
106 .Op Cm minpoll Ar minpoll
107 .Op Cm maxpoll Ar maxpoll
109 .It Xo Ic peer Ar address
110 .Op Cm key Ar key \&| Cm autokey
111 .Op Cm version Ar version
113 .Op Cm minpoll Ar minpoll
114 .Op Cm maxpoll Ar maxpoll
116 .It Xo Ic broadcast Ar address
117 .Op Cm key Ar key \&| Cm autokey
118 .Op Cm version Ar version
120 .Op Cm minpoll Ar minpoll
123 .It Xo Ic manycastclient Ar address
124 .Op Cm key Ar key \&| Cm autokey
125 .Op Cm version Ar version
127 .Op Cm minpoll Ar minpoll
128 .Op Cm maxpoll Ar maxpoll
133 These four commands specify the time server name or address to
134 be used and the mode in which to operate.
138 either a DNS name or an IP address in dotted-quad notation.
139 Additional information on association behavior can be found in the
140 .Qq "Association Management"
142 .Bl -tag -width indent
144 For type s and r addresses, this command mobilizes a persistent
145 client mode association with the specified remote server or local
147 In this mode the local clock can synchronized to the
148 remote server, but the remote server can never be synchronized to
155 For type s addresses (only), this command mobilizes a
156 persistent symmetric-active mode association with the specified
158 In this mode the local clock can be synchronized to
159 the remote peer or the remote peer can be synchronized to the local
161 This is useful in a network of servers where, depending on
162 various failure scenarios, either the local or remote peer may be
163 the better source of time.
164 This command should NOT be used for type
167 For type b and m addresses (only), this
168 command mobilizes a persistent broadcast mode association.
170 commands can be used to specify multiple local broadcast interfaces
171 (subnets) and/or multiple multicast groups.
173 broadcast messages go only to the interface associated with the
174 subnet specified, but multicast messages go to all interfaces.
175 In broadcast mode the local server sends periodic broadcast
176 messages to a client population at the
178 specified, which is usually the broadcast address on (one of) the
179 local network(s) or a multicast address assigned to NTP.
181 has assigned the multicast group address 224.0.1.1 exclusively to
182 NTP, but other nonconflicting addresses can be used to contain the
183 messages within administrative boundaries.
185 specification applies only to the local server operating as a
186 sender; for operation as a broadcast client, see the
192 .It Ic manycastclient
193 For type m addresses (only), this command mobilizes a
194 manycast client mode association for the multicast address
196 In this case a specific address must be supplied which
197 matches the address used on the
200 the designated manycast servers.
201 The NTP multicast address
202 224.0.1.1 assigned by the IANA should NOT be used, unless specific
203 means are taken to avoid spraying large areas of the Internet with
204 these messages and causing a possibly massive implosion of replies
208 command specifies that the local server
209 is to operate in client mode with the remote servers that are
210 discovered as the result of broadcast/multicast messages.
212 client broadcasts a request message to the group address associated
215 and specifically enabled
216 servers respond to these messages.
217 The client selects the servers
218 providing the best time and continues as with the
221 The remaining servers are discarded as if never
226 .Bl -tag -width indent
228 All packets sent to and received from the server or peer are to
229 include authentication fields encrypted using the autokey scheme
231 .Sx Authentication Options .
233 when the server is reachable and at each poll interval, send a
234 burst of eight packets instead of the usual one packet.
236 between the first and the second packets is about 16s to allow a
237 modem call to complete, while the spacing between the remaining
239 This is designed to improve timekeeping
245 When the server is unreachable and at each poll interval, send
246 a burst of eight packets instead of the usual one.
248 server is unreachable, the spacing between packets is about 16s to
249 allow a modem call to complete.
250 Once the server is reachable, the
251 spacing between packets is about 2s.
252 This is designed to speed the
253 initial synchronization acquisition with the
255 command and s addresses and when
262 All packets sent to and received from the server or peer are to
263 include authentication fields encrypted using the specified
265 identifier with values from 1 to 65534, inclusive.
267 default is to include no encryption field.
268 .It Cm minpoll Ar minpoll
269 .It Cm maxpoll Ar maxpoll
270 These options specify the minimum and maximum poll intervals
271 for NTP messages, in seconds to the power of two.
273 interval defaults to 10 (1,024 s), but can be increased by the
275 option to an upper limit of 17 (36.4 h).
277 minimum poll interval defaults to 6 (64 s), but can be decreased by
280 option to a lower limit of 4 (16 s).
282 Marks the server as preferred.
283 All other things being equal,
284 this host will be chosen for synchronization among a set of
285 correctly operating hosts.
287 .Qq "Mitigation Rules and the prefer Keyword"
291 This option is used only with broadcast server and manycast
293 It specifies the time-to-live
296 use on broadcast server and multicast server and the maximum
298 for the expanding ring search with manycast
300 Selection of the proper value, which defaults to
301 127, is something of a black art and should be coordinated with the
302 network administrator.
303 .It Cm version Ar version
304 Specifies the version number to be used for outgoing NTP
306 Versions 1-4 are the choices, with version 4 the
309 .Ss Auxiliary Commands
310 .Bl -tag -width indent
311 .It Ic broadcastclient
312 This command enables reception of broadcast server messages to
313 any local interface (type b) address.
314 Upon receiving a message for
315 the first time, the broadcast client measures the nominal server
316 propagation delay using a brief client/server exchange with the
317 server, then enters the broadcast client mode, in which it
318 synchronizes to succeeding broadcast messages.
320 to avoid accidental or malicious disruption in this mode, both the
321 server and client should operate using symmetric-key or public-key
322 authentication as described in
323 .Sx Authentication Options .
324 .It Ic manycastserver Ar address ...
325 This command enables reception of manycast client messages to
326 the multicast group address(es) (type m) specified.
328 address is required, but the NTP multicast address 224.0.1.1
329 assigned by the IANA should NOT be used, unless specific means are
330 taken to limit the span of the reply and avoid a possibly massive
331 implosion at the original sender.
332 Note that, in order to avoid
333 accidental or malicious disruption in this mode, both the server
334 and client should operate using symmetric-key or public-key
335 authentication as described in
336 .Sx Authentication Options .
337 .It Ic multicastclient Ar address ...
338 This command enables reception of multicast server messages to
339 the multicast group address(es) (type m) specified.
341 a message for the first time, the multicast client measures the
342 nominal server propagation delay using a brief client/server
343 exchange with the server, then enters the broadcast client mode, in
344 which it synchronizes to succeeding multicast messages.
346 in order to avoid accidental or malicious disruption in this mode,
347 both the server and client should operate using symmetric-key or
348 public-key authentication as described in
349 .Sx Authentication Options .
351 .Sh Authentication Support
352 Authentication support allows the NTP client to verify that the
353 server is in fact known and trusted and not an intruder intending
354 accidentally or on purpose to masquerade as that server.
356 specification RFC-1305 defines a scheme which provides
357 cryptographic authentication of received NTP packets.
359 this was done using the Data Encryption Standard (DES) algorithm
360 operating in Cipher Block Chaining (CBC) mode, commonly called
362 Subsequently, this was augmented by the RSA Message Digest
363 5 (MD5) algorithm using a private key, commonly called keyed-MD5.
364 Either algorithm computes a message digest, or one-way hash, which
365 can be used to verify the server has the correct private key and
368 NTPv4 retains the NTPv3 schemes, properly described as
369 symmetric-key cryptography and, in addition, provides a new Autokey
370 scheme based on public-key cryptography.
371 Public-key cryptography is
372 generally considered more secure than symmetric-key cryptography,
373 since the security is based on a private value which is generated
374 by each server and never revealed.
376 distribution and management functions involve only public values,
377 which considerably simplifies key distribution and storage.
379 Authentication is configured separately for each association
390 commands as described in
391 .Sx Configuration Options .
393 options described below specify the suite of keys, select the key
394 for each configured association and manage the configuration
399 flag controls whether new associations or
400 remote configuration commands require cryptographic authentication.
401 This flag can be set or reset by the
405 configuration commands and also by remote
406 configuration commands sent by a
410 If this flag is enabled, which is the default
411 case, new broadcast client and symmetric passive associations and
412 remote configuration commands must be cryptographically
413 authenticated using either symmetric-key or public-key schemes.
415 this flag is disabled, these operations are effective even if not
416 cryptographic authenticated.
417 It should be understood that operating
418 in the latter mode invites a significant vulnerability where a
419 rogue hacker can seriously disrupt client timekeeping.
421 In networks with firewalls and large numbers of broadcast
422 clients it may be acceptable to disable authentication, since that
423 avoids key distribution and simplifies network maintenance.
424 However, when the configuration file contains host names, or when a
425 server or client is configured remotely, host names are resolved
426 using the DNS and a separate name resolution process.
428 protect against bogus name server messages, name resolution
429 messages are authenticated using an internally generated key which
430 is normally invisible to the user.
431 However, if cryptographic
432 support is disabled, the name resolution process will fail.
434 can be avoided either by specifying IP addresses instead of host
435 names, which is generally inadvisable, or by enabling the flag for
436 name resolution and disabled it once the name resolution process is
439 An attractive alternative where multicast support is available
440 is manycast mode, in which clients periodically troll for servers.
441 Cryptographic authentication in this mode uses public-key schemes
443 The principle advantage of this manycast mode
444 is that potential servers need not be configured in advance, since
445 the client finds them during regular operation, and the
446 configuration files for all clients can be identical.
448 In addition to the default symmetric-key cryptographic support,
449 support for public-key cryptography is available if the requisite
451 software distribution has been installed before
452 building the distribution.
453 Public-key cryptography provides secure
454 authentication of servers without compromising accuracy and
456 The security model and protocol schemes for both
457 symmetric-key and public-key cryptography are described below.
458 .Ss Symmetric-Key Scheme
459 The original RFC-1305 specification allows any one of possibly
460 65,534 keys, each distinguished by a 32-bit key identifier, to
461 authenticate an association.
462 The servers and clients involved must
463 agree on the key and key identifier to authenticate their messages.
464 Keys and related information are specified in a key file, usually
467 which should be exchanged and stored
468 using secure procedures beyond the scope of the NTP protocol
470 Besides the keys used for ordinary NTP associations,
471 additional keys can be used as passwords for the
479 is first started, it reads the key file
482 command and installs the keys in the
484 However, the keys must be activated with the
487 This allows, for instance, the
488 installation of possibly several batches of keys and then
489 activating or deactivating each batch remotely using
491 This also provides a revocation capability that can
492 be used if a key becomes compromised.
495 command selects the key used as the password for the
499 command selects the key used
500 as the password for the
503 .Ss Public-Key Scheme
504 The original NTPv3 authentication scheme described in RFC-1305
505 continues to be supported; however, in NTPv4 an additional
506 authentication scheme called Autokey is available.
508 message digest, RSA public-key signature and Diffie-Hellman key
509 agreement algorithms available from several sources, but not
510 included in the NTPv4 software distribution.
514 package must be installed as
519 configure and build process automatically detects it and compiles
520 the routines required.
521 The Autokey scheme has several modes of
522 operation corresponding to the various NTP modes supported.
524 signatures with timestamps are used in all modes to verify the
525 source of cryptographic values.
526 All modes use a special cookie
527 which can be computed independently by the client and server.
529 symmetric modes the cookie is constructed using the Diffie-Hellman
530 key agreement algorithm.
531 In other modes the cookie is constructed
532 from the IP addresses and a private value known only to the server.
533 All modes use in addition a variant of the S-KEY scheme, in which a
534 pseudo-random key list is generated and used in reverse order.
535 These schemes are described along with an executive summary,
536 current status, briefing slides and reading list, in the
537 .Qq "Autonomous Authentication"
540 The cryptographic values used by the Autokey scheme are
541 incorporated as a set of files generated by the
543 program, including the
544 symmetric private keys, public/private key pair, and the agreement
548 page for a description of
549 the formats of these files.
550 They contain cryptographic values
551 generated by the algorithms of the
554 are in printable ASCII format.
555 All file names include the
556 timestamp, in NTP seconds, following the default names given below.
557 Since the file data are derived from random values seeded by the
558 system clock and the file name includes the timestamp, every
559 generation produces a different file and different file name.
563 file contains the DES/MD5 private keys.
565 must be distributed by secure means to other servers and clients
566 sharing the same security compartment and made visible only to
568 While this file is not used with the Autokey scheme, it is
569 needed to authenticate some remote configuration commands used by
577 contains the RSA private key.
578 It is useful only to the machine that
579 generated it and never shared with any other daemon or application
580 program, so must be made visible only to root.
584 file contains the agreement parameters,
585 which are used only in symmetric (active and passive) modes.
587 necessary that both peers beginning a symmetric-mode association
588 share the same parameters, but it does not matter which
591 If one of the peers contains
592 the parameters, the other peer obtains them using the Autokey
594 If both peers contain the parameters, the most recent
595 copy is used by both peers.
596 If a peer does not have the parameters,
597 they will be requested by all associations, either configured or
598 not; but, none of the associations can proceed until one of them
599 has received the parameters.
600 Once loaded, the parameters can be
601 provided on request to other clients and servers.
604 file can be also be distributed using insecure
605 means, since the data are public values.
608 .Pa ntpkey_ Ns Ar host
609 file contains the RSA public
612 is the name of the host.
615 .Pa ntpkey_ Ns Ar host
617 normally provided to other hosts using the Autokey protocol.
622 association requires the public
623 key associated with the particular server or peer to be loaded
624 either directly from a local file or indirectly from the server
625 using the Autokey protocol.
626 These files can be widely distributed
627 and stored using insecure means, since the data are public
631 .Pa ntpkey_certif_ Ns Ar host
633 the PKI certificate for the host.
634 This provides a binding between
635 the host hame and RSA public key.
636 In the current implementation the
637 certificate is obtained by a client, if present, but the contents
640 Due to the widespread use of interface-specific naming, the host
641 names used in configured and mobilized associations are determined
648 program and the Autokey protocol derive the
649 name of the public key file using the name returned by this
651 While every server and client is required to load their
652 own public and private keys, the public keys for each client or
653 peer association can be obtained from the server or peer using the
655 Note however, that at the current stage of
656 development the authenticity of the server or peer and the
657 cryptographic binding of the server name, address and public key is
658 not yet established by a certificate authority or web of trust.
659 .Ss Leapseconds Table
660 The NIST provides a table showing the epoch for all historic
661 occasions of leap second insertion since 1972.
663 shows each epoch of insertion along with the offset of
664 International Atomic Time (TAI) with respect to Coordinated
665 Universal Time (UTC), as disseminated by NTP.
667 obtained directly from NIST national time servers using
668 FTP as the ASCII file
669 .Pa pub/leap-seconds .
671 While not strictly a security function, the Autokey scheme
672 provides means to securely retrieve the leapsecond table from a
674 Servers load the leapsecond table directly from the
675 file specified in the
677 command, while clients can
678 load the table indirectly from the servers using the Autokey
680 Once loaded, the table can be provided on request to
681 other clients and servers.
683 All key files are installed by default in
685 which is normally in a shared file system
686 in NFS-mounted networks and avoids installing them in each machine
688 The default can be overridden by the
690 configuration command.
691 However, this is not a good place to install
692 the private key file, since each machine needs its own file.
694 suitable place to install it is in
697 not in a shared file system.
699 The recommended practice is to keep the timestamp extensions
700 when installing a file and to install a link from the default name
701 (without the timestamp extension) to the actual file.
703 new file generations to be activated simply by changing the link.
706 parses the link name when present to extract
707 the extension value and sends it along with the public key and host
709 This allows clients to verify that the file
710 and generation time are always current.
712 location of each file can be overridden by the
714 configuration command.
716 All cryptographic keys and related parameters should be
717 regenerated on a periodic and automatic basis, like once per month.
720 program uses the same timestamp extension
721 for all files generated at one time, so each generation is distinct
722 and can be readily recognized in monitoring data.
724 public/private key pair must be generated by every server and
725 client, the public keys and agreement parameters do not need to be
726 explicitly copied to all machines in the same security compartment,
727 since they can be obtained automatically using the Autokey
729 However, it is necessary that all primary servers have
730 the same agreement parameter file.
731 The recommended way to do this
732 is for one of the primary servers to generate that file and then
733 copy it to the other primary servers in the same compartment using
738 Future versions of the Autokey
739 protocol are to contain provisions for an agreement protocol to do
742 Servers and clients can make a new generation in the following
744 All machines have loaded the old generation at startup and are
746 At designated intervals, each machine generates
747 a new public/private key pair and makes links from the default file
748 names to the new file names.
752 and loads the new generation, with result clients no longer can
753 authenticate correctly.
754 The Autokey protocol is designed so that
755 after a few minutes the clients time out and restart the protocol
756 from the beginning, with result the new generation is loaded and
757 operation continues as before.
758 A similar procedure can be used for
759 the agreement parameter file, but in this case precautions must be
760 take to be sure that all machines with this file have the same
762 .Ss Authentication Commands
763 .Bl -tag -width indent
764 .It Ic autokey Op Ar logsec
765 Specifies the interval between regenerations of the session key
766 list used with the Autokey protocol.
767 Note that the size of the key
768 list for each association depends on this interval and the current
770 The default value is 12 (4096 s or about 1.1 hours).
771 For poll intervals above the specified interval, a session key list
772 with a single entry will be regenerated for every message
774 .It Ic controlkey Ar key
775 Specifies the key identifier to use with the
777 utility, which uses the standard
778 protocol defined in RFC-1305.
782 the key identifier for a trusted key, where the value can be in the
783 range 1 to 65534, inclusive.
785 .Op Cm flags Ar flags
786 .Op Cm privatekey Ar file
787 .Op Cm publickey Ar file
788 .Op Cm dhparms Ar file
791 This command requires the NTP daemon build process be
792 configured with the RSA library.
793 This command activates public-key
794 cryptography and loads the required RSA private and public key
795 files and the optional Diffie-Hellman agreement parameter file, if
797 If one or more files are left unspecified, the default
798 names are used as described below.
801 .Bl -tag -width indent
802 .It Cm privatekey Ar file
803 Specifies the location of the RSA private key file, which
804 otherwise defaults to
805 .Pa /usr/local/etc/ntpkey .
806 .It Cm publickey Ar file
807 Specifies the location of the RSA public key file, which
808 otherwise defaults to
809 .Pa /usr/local/etc/ntpkey_ Ns Ar host ,
812 is the name of the generating machine.
813 .It Cm dhparms Ar file
814 Specifies the location of the Diffie-Hellman parameters file,
815 which otherwise defaults to
816 .Pa /usr/local/etc/ntpkey_dh .
818 Specifies the location of the leapsecond table file, which
819 otherwise defaults to
820 .Pa /usr/local/etc/ntpkey_leap .
822 .It Ic keys Ar keyfile
823 Specifies the location of the DES/MD5 private key file
824 containing the keys and key identifiers used by
829 when operating in symmetric-key
831 .It Ic keysdir Ar path
832 This command requires the NTP daemon build process be
833 configured with the RSA library.
834 It specifies the default directory
835 path for the private key file, agreement parameters file and one or
836 more public key files.
837 The default when this command does not
838 appear in the configuration file is
840 .It Ic requestkey Ar key
841 Specifies the key identifier to use with the
843 utility program, which uses a
844 proprietary protocol specific to this implementation of
848 argument is a key identifier
849 for the trusted key, where the value can be in the range 1 to
851 .It Ic revoke Ar logsec
852 Specifies the interval between re-randomization of certain
853 cryptographic values used by the Autokey scheme, as a power of 2 in
855 These values need to be updated frequently in order to
856 deflect brute-force attacks on the algorithms of the scheme;
857 however, updating some values is a relatively expensive operation.
858 The default interval is 16 (65,536 s or about 18 hours).
860 intervals above the specified interval, the values will be updated
861 for every message sent.
862 .It Ic trustedkey Ar key ...
863 Specifies the key identifiers which are trusted for the
864 purposes of authenticating peers with symmetric-key cryptography,
865 as well as keys used by the
870 The authentication procedures require that both the local
871 and remote servers share the same key and key identifier for this
872 purpose, although different keys can be used with different
876 arguments are 32-bit unsigned
877 integers with values from 1 to 65,534.
879 .Sh Monitoring Support
881 includes a comprehensive monitoring facility suitable
882 for continuous, long term recording of server and client
883 timekeeping performance.
887 for a listing and example of each type of statistics currently
889 Statistic files are managed using file generation sets
892 directory of this distribution.
897 jobs, the data can be
898 automatically summarized and archived for retrospective analysis.
899 .Ss Monitoring Commands
900 .Bl -tag -width indent
901 .It Ic statistics Ar name ...
902 Enables writing of statistics records.
903 Currently, four kinds of
905 statistics are supported.
906 .Bl -tag -width indent
908 Enables recording of loop filter statistics information.
910 update of the local clock outputs a line of the following form to
911 the file generation set named loopstats:
913 50935 75440.031 0.000006019 13.778190 0.000351733 0.013380 6
916 The first two fields show the date (Modified Julian Day) and
917 time (seconds and fraction past UTC midnight).
919 show time offset (seconds), frequency offset (parts per million -
920 PPM), RMS jitter (seconds), Allan deviation (PPM) and clock
921 discipline time constant.
923 Enables recording of peer statistics information.
925 statistics records of all peers of a NTP server and of special
926 signals, where present and configured.
927 Each valid update appends a
928 line of the following form to the current element of a file
929 generation set named peerstats:
931 48773 10847.650 127.127.4.1 9714 -0.001605 0.00000 0.00142
934 The first two fields show the date (Modified Julian Day) and
935 time (seconds and fraction past UTC midnight).
937 show the peer address in dotted-quad notation and status,
939 The status field is encoded in hex in the format
940 described in Appendix A of the NTP specification RFC 1305.
942 final three fields show the offset, delay and RMS jitter, all in
945 Enables recording of clock driver statistics information.
947 update received from a clock driver appends a line of the following
948 form to the file generation set named clockstats:
950 49213 525.624 127.127.4.1 93 226 00:08:29.606 D
953 The first two fields show the date (Modified Julian Day) and
954 time (seconds and fraction past UTC midnight).
956 the clock address in dotted-quad notation.
957 The final field shows
958 the last timecode received from the clock in decoded ASCII format,
960 In some clock drivers a good deal of additional
961 information can be gathered and displayed as well.
963 specific to each clock for further details.
965 Enables recording of raw-timestamp statistics information.
967 includes statistics records of all peers of a NTP server and of
968 special signals, where present and configured.
970 received from a peer or clock driver appends a line of the
971 following form to the file generation set named rawstats:
973 50928 2132.543 128.4.1.1 128.4.1.20 3102453281.584327000 3102453281.58622800031 02453332.540806000 3102453332.541458000
975 The first two fields show the date (Modified Julian Day) and
976 time (seconds and fraction past UTC midnight).
978 show the remote peer or clock address followed by the local address
979 in dotted-quad notation.
980 The final four fields show the originate,
981 receive, transmit and final NTP timestamps in order.
983 values are as received and before processing by the various data
984 smoothing and mitigation algorithms.
986 .It Ic statsdir Ar directory_path
987 Indicates the full path of a directory where statistics files
988 should be created (see below).
989 This keyword allows the (otherwise
992 filename prefix to be modified for file
993 generation sets, which is useful for handling statistics logs.
994 .It Xo Ic filegen Ar name
995 .Op Cm file Ar filename
996 .Op Cm type Ar typename
997 .Op Cm link \&| Cm nolink
998 .Op Cm enable \&| Cm disable
1000 Configures setting of generation file set
1002 Generation file sets provide a means for handling files that are
1003 continuously growing during the lifetime of a server.
1005 statistics are a typical example for such files.
1007 sets provide access to a set of files used to store the actual
1009 At any time at most one element of the set is being written
1011 The type given specifies when and how data will be directed to
1012 a new element of the set.
1013 This way, information stored in elements
1014 of a file set that are currently unused are available for
1015 administrational operations without the risk of disturbing the
1018 (Most important: they can be removed to
1019 free space for new data produced.)
1020 Note that this command can be sent from the
1022 program running at a remote location.
1023 .Bl -tag -width indent
1025 This is the type of the statistics records, as shown in the
1028 .It Cm file Ar filename
1029 This is the file name for the statistics records.
1031 set members are built from three concatenated elements
1032 prefix, filename and
1034 .Bl -tag -width indent
1036 This is a constant filename path.
1037 It is not subject to
1038 modifications via the
1041 It is defined by the
1042 server, usually specified as a compile-time constant.
1044 however, be configurable for individual file generation sets via
1046 For example, the prefix used with
1051 configured using the
1053 option explained above.
1055 This string is directly concatenated to the prefix mentioned
1056 above (no intervening
1059 This can be modified
1067 elements are allowed in this component to prevent
1068 filenames referring to parts outside the file system hierarchy
1071 This part is reflects individual elements of a file set.
1073 generated according to the type of a file set.
1075 .It Cm type Ar typename
1076 A file generation set is characterized by its type.
1078 following types are supported:
1079 .Bl -tag -width indent
1081 The file set is actually a single plain file.
1083 One element of file set is used per incarnation of a
1086 This type does not perform any changes to
1087 file set members during runtime, however it provides an easy way of
1088 separating files belonging to different
1092 The set member filename is built by appending a
1094 (dot) to concatenated prefix and filename
1095 strings, and appending the decimal representation of the process ID
1100 One file generation set element is created per day.
1102 defined as the period between 00:00 and 24:00 UTC.
1104 member suffix consists of a
1107 specification in the form
1111 number (e.g., 1992).
1113 is a two digit month number.
1115 is a two digit day number.
1116 Thus, all information
1117 written at 10 December 1992 would end up in a file named
1119 .Pa Ar prefix / Ar filename / 19921210 .
1122 Any file set member contains data related to a certain week of
1124 The term week is defined by computing day-of-year modulo 7.
1125 Elements of such a file generation set are distinguished by
1126 appending the following suffix to the file set filename base: A
1127 dot, a 4-digit year number, the letter
1131 For example, information from January, 10th 1992 would
1132 end up in a file with suffix
1135 One generation file set element is generated per month.
1137 file name suffix consists of a dot, a 4-digit year number, and a
1140 One generation file element is generated per year.
1142 suffix consists of a dot and a 4 digit year number.
1144 This type of file generation sets changes to a new element of
1145 the file set every 24 hours of server operation.
1147 suffix consists of a dot, the letter
1151 This number is taken to be the number of seconds the server
1152 is running at the start of the corresponding 24-hour period.
1153 Information is only written to a file generation by specifying
1155 output is prevented by specifying
1158 .It Cm link \&| Cm nolink
1159 It is convenient to be able to access the current element of a
1160 file generation set by a fixed name.
1161 This feature is enabled by
1168 is specified, a hard link from the current file set
1169 element to a file without suffix is created.
1170 When there is already
1171 a file with this name and the number of links of this file is one,
1172 it is renamed appending a dot, the letter
1178 When the number of links is
1179 greater than one, the file is unlinked.
1180 This allows the current
1181 file to be accessed by a constant name.
1182 .It Cm enable \&| Cm disable
1183 Enables or disables the recording function.
1186 .Sh Access Control Support
1188 implements a general purpose address-and-mask based
1190 The list is sorted by address and by mask, and
1191 the list is searched in this order for matches, with the last match
1192 found defining the restriction flags associated with the incoming
1194 The source address of incoming packets is used for the
1195 match, with the 32- bit address being and'ed with the mask
1196 associated with the restriction entry and then compared with the
1197 entry's address (which has also been and'ed with the mask) to look
1199 Additional information and examples can be found in the
1200 .Qq "Notes on Configuring NTP and Setting up a NTP Subnet"
1203 The restriction facility was implemented in conformance with the
1204 access policies for the original NSFnet backbone time servers.
1205 While this facility may be otherwise useful for keeping unwanted or
1206 broken remote time servers from affecting your own, it should not
1207 be considered an alternative to the standard NTP authentication
1209 Source address based restrictions are easily circumvented
1210 by a determined cracker.
1211 .Ss The Kiss-of-Death Packet
1212 Ordinarily, packets denied service are simply dropped with no
1213 further action except incrementing statistics counters.
1215 more proactive response is needed, such as a server message that
1216 explicitly requests the client to stop sending and leave a message
1217 for the system operator.
1218 A special packet format has been created
1219 for this purpose called the kiss-of-death packet.
1222 flag is set and either service is denied or the client
1223 limit is exceeded, the server returns the packet and sets the
1224 leap bits unsynchronized, stratum zero and the ASCII string "DENY"
1225 in the reference source identifier field.
1229 is not set, the server simply drops the packet.
1231 A client or peer receiving a kiss-of-death packet performs a set
1232 of sanity checks to minimize security exposure.
1234 first packet received from the server, the client assumes an access
1235 denied condition at the server.
1236 It updates the stratum and
1237 reference identifier peer variables and sets the access denied
1238 (test 4) bit in the peer flash variable.
1239 If this bit is set, the
1240 client sends no packets to the server.
1241 If this is not the first
1242 packet, the client assumes a client limit condition at the server,
1243 but does not update the peer variables.
1244 In either case, a message
1245 is sent to the system log.
1246 .Ss Access Control Commands
1247 .Bl -tag -width indent
1248 .It Xo Ic restrict numeric_address
1249 .Op Cm mask Ar numeric_mask
1254 argument, expressed in
1255 dotted-quad form, is the address of a host or network.
1258 also expressed in dotted-quad form,
1259 defaults to 255.255.255.255, meaning that the
1261 is treated as the address of an
1263 A default entry (address 0.0.0.0, mask
1264 0.0.0.0) is always included and, given the sort algorithm,
1265 is always the first entry in the list.
1268 is normally given in dotted-quad
1269 format, the text string
1271 with no mask option, may
1272 be used to indicate the default entry.
1273 In the current implementation,
1276 restricts access, i.e., an entry with no flags indicates that free
1277 access to the server is to be given.
1278 The flags are not orthogonal,
1279 in that more restrictive flags will often make less restrictive
1281 The flags can generally be classed into two
1282 categories, those which restrict time service and those which
1283 restrict informational queries and attempts to do run-time
1284 reconfiguration of the server.
1285 One or more of the following flags
1287 .Bl -tag -width indent
1289 If access is denied, send a kiss-of-death packet.
1291 Ignore all packets from hosts which match this entry.
1293 flag is specified neither queries nor time server polls will be
1296 Ignore all NTP mode 6 and 7 packets (i.e. information queries
1297 and configuration requests) from the source.
1301 Ignore all NTP mode 6 and 7 packets which attempt to modify the
1302 state of the server (i.e. run time reconfiguration).
1304 return information are permitted.
1306 Decline to provide mode 6 control message trap service to
1308 The trap service is a subsystem of the mode 6
1309 control message protocol which is intended for use by remote event
1312 Declare traps set by matching hosts to be low priority.
1314 number of traps a server can maintain is limited (the current limit
1316 Traps are usually assigned on a first come, first served
1317 basis, with later trap requestors being denied service.
1319 modifies the assignment algorithm by allowing low priority traps to
1320 be overridden by later requests for normal priority traps.
1322 Ignore NTP packets whose mode is other than 6 or 7.
1324 time service is denied, though queries may still be permitted.
1326 Provide stateless time service to polling hosts, but do not
1327 allocate peer memory resources to these hosts even if they
1328 otherwise might be considered useful as future synchronization
1331 Treat these hosts normally in other respects, but never use
1332 them as synchronization sources.
1334 These hosts are subject to limitation of number of clients from
1336 Net in this context refers to the IP notion of net
1337 (class A, class B, class C, etc.).
1340 hosts that have shown up at the server and
1341 that have been active during the last
1342 .Va client_limit_period
1343 seconds are accepted.
1344 Requests from other clients from the same net
1346 Only time request packets are taken into account.
1347 Query packets sent by the
1352 are not subject to these limits.
1353 A history of clients is kept using
1354 the monitoring capability of
1357 always active as long as there is a restriction entry with the
1361 This is actually a match algorithm modifier, rather than a
1363 Its presence causes the restriction entry to be
1364 matched only if the source port in the packet is the standard NTP
1374 is considered more specific and
1375 is sorted later in the list.
1377 Ignore these hosts if not the current NTP version.
1380 Default restriction list entries, with the flags
1384 for each of the local host's interface
1385 addresses are inserted into the table at startup to prevent the
1386 server from attempting to synchronize to its own time.
1388 entry is also always present, though if it is otherwise
1389 unconfigured; no flags are associated with the default entry (i.e.,
1390 everything besides your own NTP server is unrestricted).
1391 .It Ic clientlimit Ar limit
1394 variable, which limits the number
1395 of simultaneous access-controlled clients.
1396 The default value for
1398 .It Ic clientperiod Ar period
1400 .Va client_limit_period
1401 variable, which specifies
1402 the number of seconds after which a client is considered inactive
1403 and thus no longer is counted for client limit restriction.
1405 default value for this variable is 3600 seconds.
1407 .Sh Reference Clock Support
1408 The NTP Version 4 daemon supports some three dozen different radio,
1409 satellite and modem reference clocks plus a special pseudo-clock
1410 used for backup or when no other clock source is available.
1411 Detailed descriptions of individual device drivers and options can
1413 .Qq "Reference Clock Drivers"
1415 (available as part of the HTML documentation
1417 .Pa /usr/share/doc/ntp ) .
1418 Additional information can be found in the pages linked
1419 there, including the
1420 .Qq "Debugging Hints for Reference Clock Drivers"
1422 .Qq "How To Write a Reference Clock Driver"
1424 In addition, support for a PPS
1425 signal is available as described in the
1426 .Qq "Pulse-per-second (PPS) Signal Interfacing"
1429 drivers support special line discipline/streams modules which can
1430 significantly improve the accuracy using the driver.
1433 .Qq "Line Disciplines and Streams Drivers"
1436 A reference clock will generally (though not always) be a radio
1437 timecode receiver which is synchronized to a source of standard
1438 time such as the services offered by the NRC in Canada and NIST and
1440 The interface between the computer and the timecode
1441 receiver is device dependent, but is usually a serial port.
1443 device driver specific to each reference clock must be selected and
1444 compiled in the distribution; however, most common radio, satellite
1445 and modem clocks are included by default.
1446 Note that an attempt to
1447 configure a reference clock when the driver has not been compiled
1448 or the hardware port has not been appropriately configured results
1449 in a scalding remark to the system log file, but is otherwise non
1452 For the purposes of configuration,
1455 reference clocks in a manner analogous to normal NTP peers as much
1457 Reference clocks are identified by a syntactically
1458 correct but invalid IP address, in order to distinguish them from
1460 Reference clock addresses are of the form
1462 .Li 127.127. Ar t . Ar u ,
1467 denoting the clock type and
1470 number in the range 0-3.
1471 While it may seem overkill, it is in fact
1472 sometimes useful to configure multiple reference clocks of the same
1473 type, in which case the unit numbers must be unique.
1477 command is used to configure a reference
1480 argument in that command
1481 is the clock address.
1487 options are not used for reference clock support.
1490 option is added for reference clock support, as
1494 option can be useful to
1495 persuade the server to cherish a reference clock with somewhat more
1496 enthusiasm than other reference clocks or peers.
1498 information on this option can be found in the
1499 .Qq "Mitigation Rules and the prefer Keyword"
1506 meaning only for selected clock drivers.
1507 See the individual clock
1508 driver document pages for additional information.
1512 command is used to provide additional
1513 information for individual clock drivers and normally follows
1514 immediately after the
1519 argument specifies the clock address.
1524 options can be used to
1525 override the defaults for the device.
1526 There are two optional
1527 device-dependent time offsets and four flags that can be included
1532 The stratum number of a reference clock is by default zero.
1535 daemon adds one to the stratum of each
1536 peer, a primary server ordinarily displays an external stratum of
1538 In order to provide engineered backups, it is often useful to
1539 specify the reference clock stratum as greater than zero.
1542 option is used for this purpose.
1544 involving both a reference clock and a pulse-per-second (PPS)
1545 discipline signal, it is useful to specify the reference clock
1546 identifier as other than the default, depending on the driver.
1549 option is used for this purpose.
1551 these options apply to all clock drivers.
1552 .Ss Reference Clock Commands
1553 .Bl -tag -width indent
1556 .Li 127.127. Ar t . Ar u
1560 .Op Cm minpoll Ar int
1561 .Op Cm maxpoll Ar int
1563 This command can be used to configure reference clocks in
1565 The options are interpreted as follows:
1566 .Bl -tag -width indent
1568 Marks the reference clock as preferred.
1569 All other things being
1570 equal, this host will be chosen for synchronization among a set of
1571 correctly operating hosts.
1573 .Qq "Mitigation Rules and the prefer Keyword"
1577 Specifies a mode number which is interpreted in a
1578 device-specific fashion.
1579 For instance, it selects a dialing
1580 protocol in the ACTS driver and a device subtype in the
1583 .It Cm minpoll Ar int
1584 .It Cm maxpoll Ar int
1585 These options specify the minimum and maximum polling interval
1586 for reference clock messages, in seconds to the power of two.
1588 most directly connected reference clocks, both
1592 default to 6 (64 s).
1593 For modem reference clocks,
1595 defaults to 10 (17.1 m) and
1597 defaults to 14 (4.5 h).
1598 The allowable range is 4 (16 s) to 17 (36.4 h) inclusive.
1602 .Li 127.127. Ar t . Ar u
1606 .Op Cm stratum Ar int
1607 .Op Cm refid Ar string
1609 .Op Cm flag1 Cm 0 \&| Cm 1
1610 .Op Cm flag2 Cm 0 \&| Cm 1
1611 .Op Cm flag3 Cm 0 \&| Cm 1
1612 .Op Cm flag4 Cm 0 \&| Cm 1
1614 This command can be used to configure reference clocks in
1616 It must immediately follow the
1618 command which configures the driver.
1619 Note that the same capability
1620 is possible at run time using the
1623 The options are interpreted as
1625 .Bl -tag -width indent
1627 Specifies a constant to be added to the time offset produced by
1628 the driver, a fixed-point decimal number in seconds.
1630 as a calibration constant to adjust the nominal time offset of a
1631 particular clock to agree with an external standard, such as a
1632 precision PPS signal.
1633 It also provides a way to correct a
1634 systematic error or bias due to serial port or operating system
1635 latencies, different cable lengths or receiver internal delay.
1637 specified offset is in addition to the propagation delay provided
1638 by other means, such as internal DIPswitches.
1640 for an individual system and driver is available, an approximate
1641 correction is noted in the driver documentation pages.
1642 Note: in order to facilitate calibration when more than one
1643 radio clock or PPS signal is supported, a special calibration
1644 feature is available.
1645 It takes the form of an argument to the
1647 command described in
1648 .Sx Miscellaneous Options
1649 page and operates as described in the
1650 .Qq "Reference Clock Drivers"
1652 .It Cm time2 Ar secs
1653 Specifies a fixed-point decimal number in seconds, which is
1654 interpreted in a driver-dependent way.
1655 See the descriptions of
1656 specific drivers in the
1657 .Qq "reference clock drivers"
1659 .It Cm stratum Ar int
1660 Specifies the stratum number assigned to the driver, an integer
1662 This number overrides the default stratum number
1663 ordinarily assigned by the driver itself, usually zero.
1664 .It Cm refid Ar string
1665 Specifies an ASCII string of from one to four characters which
1666 defines the reference identifier used by the driver.
1668 overrides the default identifier ordinarily assigned by the driver
1671 Specifies a mode number which is interpreted in a
1672 device-specific fashion.
1673 For instance, it selects a dialing
1674 protocol in the ACTS driver and a device subtype in the
1677 .It Cm flag1 Cm 0 \&| Cm 1
1678 .It Cm flag2 Cm 0 \&| Cm 1
1679 .It Cm flag3 Cm 0 \&| Cm 1
1680 .It Cm flag4 Cm 0 \&| Cm 1
1681 These four flags are used for customizing the clock driver.
1683 interpretation of these values, and whether they are used at all,
1684 is a function of the particular clock driver.
1688 is used to enable recording monitoring
1691 file configured with the
1694 Further information on the
1696 command can be found in
1697 .Sx Monitoring Options .
1700 .Sh Miscellaneous Options
1701 .Bl -tag -width indent
1702 .It Ic broadcastdelay Ar seconds
1703 The broadcast and multicast modes require a special calibration
1704 to determine the network delay between the local and remote
1706 Ordinarily, this is done automatically by the initial
1707 protocol exchanges between the client and server.
1709 the calibration procedure may fail due to network or server access
1710 controls, for example.
1711 This command specifies the default delay to
1712 be used under these circumstances.
1713 Typically (for Ethernet), a
1714 number between 0.003 and 0.007 seconds is appropriate.
1716 when this command is not used is 0.004 seconds.
1717 .It Ic driftfile Ar driftfile
1718 This command specifies the name of the file used to record the
1719 frequency offset of the local clock oscillator.
1721 it is read at startup in order to set the initial frequency offset
1722 and then updated once per hour with the current frequency offset
1723 computed by the daemon.
1724 If the file does not exist or this command
1725 is not given, the initial frequency offset is assumed zero.
1727 case, it may take some hours for the frequency to stabilize and the
1728 residual timing errors to subside.
1730 The file format consists of a single line containing a single
1731 floating point number, which records the frequency offset measured
1732 in parts-per-million (PPM).
1733 The file is updated by first writing
1734 the current drift value into a temporary file and then renaming
1735 this file to replace the old version.
1738 must have write permission for the directory the
1739 drift file is located in, and that file system links, symbolic or
1740 otherwise, should be avoided.
1743 .Cm auth | Cm bclient |
1744 .Cm calibrate | Cm kernel |
1745 .Cm monitor | Cm ntp |
1751 .Cm auth | Cm bclient |
1752 .Cm calibrate | Cm kernel |
1753 .Cm monitor | Cm ntp |
1757 Provides a way to enable or disable various server options.
1758 Flags not mentioned are unaffected.
1759 Note that all of these flags
1760 can be controlled remotely using the
1763 .Bl -tag -width indent
1765 When enabled, this is identical to the
1768 The default for this flag is
1771 Enables the calibration facility, which automatically adjusts
1774 values for each clock driver to display the same
1775 offset as the currently selected source or kernel discipline
1778 .Qq "Reference Clock Drivers"
1780 for further information.
1781 The default for this flag is
1784 Enables the precision-time kernel support for the
1786 system call, if implemented.
1788 support for this routine is detected automatically when the NTP
1789 daemon is compiled, so it is not necessary for the user to worry
1791 It is provided primarily so that this support
1792 can be disabled during kernel development.
1793 The default for this
1797 Enables the monitoring facility.
1803 command or further information.
1805 default for this flag is
1808 Enables the server to adjust its local clock by means of NTP.
1809 If disabled, the local clock free-runs at its intrinsic time and
1811 This flag is useful in case the local clock is
1812 controlled by some other device or protocol and NTP is used only to
1813 provide synchronization to other clients.
1814 In this case, the local
1815 clock driver can be used to provide this function and also certain
1816 time variables for error estimates and leap-indicators.
1818 .Qq "Reference Clock Drivers"
1821 The default for this flag is
1824 Enables the statistics facility.
1826 .Qq "Monitoring Options"
1827 page for further information.
1828 The default for this flag is
1831 .It Ic logconfig Ar configkeyword
1832 This command controls the amount and type of output written to
1835 facility or the alternate
1838 By default, all output is turned on.
1841 keywords can be prefixed with
1857 messages can be controlled in four
1866 Within these classes four types of messages can be
1868 Informational messages
1870 control configuration
1875 events (reachability, synchronization, alarm conditions).
1876 Statistical output is controlled with the
1879 The final message group is the status messages.
1881 describes mainly the synchronizations status.
1883 keywords are formed by concatenating the message class with the
1887 prefix can be used instead of a
1889 A message class may also be followed by the
1891 keyword to enable/disable all messages of the
1892 respective message class.
1893 Thus, a minimal log configuration could look like this:
1895 logconfig=syncstatus +sysevents
1898 This would just list the synchronizations state of
1900 and the major system events.
1901 For a simple reference server, the
1902 following minimum message configuration could be useful:
1904 logconfig=syncall +clockall
1907 This configuration will list all clock information and
1908 synchronization information.
1909 All other events and messages about
1910 peers, system events and so on is suppressed.
1911 .It Ic logfile Ar logfile
1912 This command specifies the location of an alternate log file to
1913 be used instead of the default system
1916 .It Ic setvar Ar variable Op Cm default
1917 This command adds an additional system variable.
1919 variables can be used to distribute additional information such as
1921 If the variable of the form
1928 variable will be listed as part of the default system variables
1934 These additional variables serve
1935 informational purposes only.
1936 They are not related to the protocol
1937 other that they can be listed.
1938 The known protocol variables will
1939 always override any variables defined via the
1942 There are three special variables that contain the names
1943 of all variable of the same group.
1947 the names of all system variables.
1951 the names of all peer variables and the
1953 holds the names of the reference clock variables.
1957 .Cm panic Ar panic |
1958 .Cm dispersion Ar dispersion |
1959 .Cm stepout Ar stepout |
1960 .Cm minpoll Ar minpoll |
1961 .Cm allan Ar allan |
1962 .Cm huffpuff Ar huffpuff
1965 This command can be used to alter several system variables in
1966 very exceptional circumstances.
1967 It should occur in the
1968 configuration file before any other configuration options.
1970 default values of these variables have been carefully optimized for
1971 a wide range of network speeds and reliability expectations.
1973 general, they interact in intricate ways that are hard to predict
1974 and some combinations can result in some very nasty behavior.
1976 rarely is it necessary to change the default values; but, some
1977 folks can't resist twisting the knobs anyway and this command is
1979 Emphasis added: twisters are on their own and can expect
1980 no help from the support group.
1982 All arguments are in floating point seconds or seconds per
1986 argument is an integer in seconds to
1988 The variables operate as follows:
1989 .Bl -tag -width indent
1991 The argument becomes the new value for the step threshold,
1993 If set to zero, step adjustments will never
1995 In general, if the intent is only to avoid step adjustments,
1996 the step threshold should be left alone and the
1999 line option be used instead.
2000 .It Cm panic Ar panic
2001 The argument becomes the new value for the panic threshold,
2003 If set to zero, the panic sanity check is disabled
2004 and a clock offset of any value will be accepted.
2005 .It Cm dispersion Ar dispersion
2006 The argument becomes the new value for the dispersion increase
2007 rate, normally .000015.
2008 .It Cm stepout Ar stepout
2009 The argument becomes the new value for the watchdog timeout,
2011 .It Cm minpoll Ar minpoll
2012 The argument becomes the new value for the minimum poll
2013 interval used when configuring multicast client, manycast client
2014 and , symmetric passive mode association.
2015 The value defaults to 6
2016 (64 s) and has a lower limit of 4 (16 s).
2017 .It Cm allan Ar allan
2018 The argument becomes the new value for the minimum Allan
2019 intercept, which is a parameter of the PLL/FLL clock discipline
2021 The value defaults to 1024 s, which is also the lower
2023 .It Cm huffpuff Ar huffpuff
2024 The argument becomes the new value for the experimental
2025 huff-n'-puff filter span, which determines the most recent interval
2026 the algorithm will search for a minimum delay.
2028 900 s (15 m), but a more reasonable value is 7200 (2 hours).
2030 is no default, since the filter is not enabled unless this command
2033 .It Xo Ic trap Ar host_address
2034 .Op Cm port Ar port_number
2035 .Op Cm interface Ar interface_address
2037 This command configures a trap receiver at the given host
2038 address and port number for sending messages with the specified
2039 local interface address.
2040 If the port number is unspecified, a value
2042 If the interface address is not specified, the
2043 message is sent with a source address of the local interface the
2044 message is sent through.
2045 Note that on a multihomed host the
2046 interface used may vary from time to time with routing changes.
2048 The trap receiver will generally log event messages and other
2049 information from the server in a log file.
2051 programs may also request their own trap dynamically, configuring a
2052 trap receiver will ensure that no messages are lost when the server
2056 .Bl -tag -width /etc/ntp.drift -compact
2057 .It Pa /etc/ntp.conf
2058 the default name of the configuration file
2063 .It Pa ntpkey_ Ns Ar host
2066 Diffie-Hellman agreement parameters
2073 In addition to the manual pages provided,
2074 comprehensive documentation is available on the world wide web
2076 .Li http://www.ntp.org/ .
2077 A snapshot of this documentation is available in HTML format in
2078 .Pa /usr/share/doc/ntp .
2081 .%T Network Time Protocol (Version 3)
2085 The syntax checking is not picky; some combinations of
2086 ridiculous and even hilarious options and modes may not be
2090 .Pa ntpkey_ Ns Ar host
2091 files are really digital
2093 These should be obtained via secure directory
2094 services when they become universally available.