NAME | SYNOPSIS | DESCRIPTION | OPTIONS | USAGE | FILES | ATTRIBUTES | SEE ALSO | NOTES
ntpd is an operating system daemon which sets and maintains a system time-of-day in agreement with Internet standard time servers. The ntpd daemon is a complete implementation of the Network Time Protocol (NTP) version 4. This daemon also retains compatibility with version 3, as defined by RFC 1305, and version 1 and 2, as defined by RFC-1059 and RFC-1119, respectively. It also retains compatibility with version 1 and 2 servers as defined by RFC 1059 and RFC 1119, respectively. ntpd does most computations in 64-bit floating point arithmetic and does 64-bit fixed point operations only when necessary to preserve the ultimate precision, about 232 picoseconds. While the ultimate precision, is not achievable with the workstations and networks of today, it may be required for future nanosecond CPU clocks and gigabit LANs.
The daemon can operate in any of several modes, including symmetric active/passive, client/server, broadcast/multicast and manycast. A broadcast/multicast or manycast client can discover remote servers, compute server-client propagation delay correction factors and configure itself automatically. This makes it possible to deploy a fleet of workstations without specifying configuration details specific to the local environment.
Ordinarily, ntpd reads the ntp.conf configuration file at startup time in order to determine the synchronization sources and operating modes. It is also possible to specify a working, although limited, configuration entirely on the command line, obviating the need for a configuration file. This may be particularly appropriate when the local host is to be configured as a broadcast/multicast client or manycast client, with all peers being determined by listening to broadcasts at run time. Various internal ntpd variables can be displayed and configuration options altered while the daemon is running using the ntpq(1M) utility program.
When ntpd starts it looks at the value of umask, and if it's zero ntpd will set the umask to 022.
The following command line options are understood by ntpd. See Configuration Commands for a more complete functional description:
Enable authentication mode (default).
Disable authentication mode.
Synchronize using NTP broadcast messages.
Specify the name and path of the configuration file.
Specify debugging mode. This flag may occur multiple times, with each occurrence indicating greater detail of display.
Specify debugging level directly.
Specify the name and path of the drift file.
Normally, the daemon exits if the offset exceeds a 1000-s sanity limit. This option overrides this limit and allows the time to be set to any value without restriction; however, this can happen only once. After that, the daemon will exit if the limit is exceeded.
Specify the name and path of the file containing the NTP authentication keys.
Specify the name and path of the log file. The default is the system log facility.
Synchronize using NTP multicast messages on the IP multicast group address 224.0.1.1.
Specify the name and path to record the daemon's process id.
Override the POSIX priority limit of the main thread. The priority value for NTP can be between 0 and 155 where 0 is the lowest priority and 155 is the highest priority. By default the priority value is set at 155. Only use this option if you are familiar with NTP.
Specify the default propagation delay from the broadcast/multicast server and this computer. This is necessary only if the delay cannot be computed automatically by the protocol.
Specify the directory path for files created by the statistics facility.
Add a key number to the trusted key list.
Add a system variable.
Add a system variable listed by default.
If you do not use this option and if the time is to be adjusted more than 128 ms, it is stepped, not gradually slewed. This option forces the time to be slewed in all cases. Note: Since the slew rate is limited to 0.5 ms/s, each second of adjustment requires an amortization interval of 2000 s. Thus, an adjustment of many seconds can take hours or days to amortize.
The ntpd configuration file is read at initial startup in order to specify the synchronization sources, modes and other related information. Usually, it is installed in the /etc directory, but could be installed elsewhere (see the -c conffile command line option). The file format is similar to other ChorusOS configuration files - comments begin with a # character and extend to the end of the line; blank lines are ignored.
Configuration commands consist of an initial keyword followed by a list of arguments, some of which may be optional, separated by white-space. Commands may not be continued over multiple lines. Arguments may be host names, host addresses written in numeric, dotted-quad form, integers, floating point numbers (when specifying times in seconds) and text strings. Optional arguments are delimited by [ ] in the following descriptions, while alternatives are separated by |. The notation [ ... ] means an optional, indefinite repetition of the last item before the [ ... ].
The various modes are determined by the command keyword and the type of the required IP address. Addresses are classed by type as
s - A remote server or peer (IP class A, B and C).
b - The broadcast address of a local interface.
m - A multicast address (IP class D).
r - A reference clock address (127.127.x.x).
These four commands specify the time server name or address to be used and the mode in which to operate. The address can be either a DNS name or an IP address in dotted-quad notation.
For type s and r addresses, server mobilizes a persistent client mode association. The server command specifies that the local server is to operate in client mode with the specified remote server. In this mode, the local server can be synchronized to the remote server, but the remote server can never be synchronized to the local server.
For type s addresses, peer operates as the current peer command, which mobilizes a persistent symmetric-active mode association, except that additional modes are available. Do not use this command for type b, m or r addresses. The peer command specifies that the local server is to operate in symmetric active mode with the remote server. In this mode, the local server can be synchronized to the remote server and, in addition, the remote server can be synchronized by the local server. This is useful in a network of servers where, depending on various failure scenarios, either the local or remote server may be the better source of time.
For type b and m addresses, broadcast operates mobilizes a persistent broadcast mode association. Additional modes are available. Multiple commands can be used to specify multiple local broadcast interfaces (subnets) and/or multiple multicast groups. Note that local broadcast messages go only to the interface associated with the subnet specified, but multicast messages go to all interfaces. In the current implementation, the source address used for these messages is the ChorusOS host default address. In broadcast mode, the local server sends periodic broadcast messages to a client population at the address specified, which is usually the broadcast address on (one of) the local network(s) or a multicast address assigned to NTP. The IANA has assigned the multicast group address 224.0.1.1 exclusively to NTP, but other non-conflicting addresses can be used to contain the messages within administrative boundaries. Ordinarily, this specification applies only to the local server operating as a sender; for operation as a broadcast client, see the broadcastclient or multicastclient commands below.
For type m addresses, manycastclient mobilizes a manycast client-mode association for the multicast address specified. In this case a specific address must be supplied which matches the address used on the manycastserver command for the designated manycast servers. Do not use the NTP multicast address 224.0.1.1 assigned by the IANA unless you have taken specific means to avoid the Internet being saturated with these messages. This could result in you receiving a very large number of replies. The manycast command specifies that the local server is to operate in client mode with the remote servers that are discovered as the result of broadcast/multicast messages. The client broadcasts a request message to the group address associated with the specified address and specifically enabled servers respond to these messages. The client selects the servers providing the best time and continues as with the server command. The remaining servers are discarded as if never heard.
At each poll interval, send a burst of eight packets spaced, instead of the usual one.
All packets sent to and received from the server or peer are to include authentication fields encrypted using the specified key identifier with values from 1 to 65534, inclusive. The default is to include no encryption field.
These options specify the minimum and maximum polling intervals for NTP messages, in seconds to the power of two. The default range is 6 (64 s) to 10 (1,024 s). The allowable range is 4 (16 s) to 17 (36.4 h) inclusive.
Marks the server as preferred. All other things being equal, this host will be chosen for synchronization among a set of correctly operating hosts.
This option is used only with broadcast mode. It specifies the time-to-live, ttl, to use on multicast packets. Selection of the appropriate value, where the default is 127, must be coordinated with the network administrator.
Specifies the version number to be used for outgoing NTP packets. Versions 1-4 are the choices, with version 4 the default.
This command directs the local server to listen for and respond to broadcast messages received on any local interface. Upon hearing a broadcast message for the first time, the local server measures the nominal network delay using a brief client/server exchange with the remote server, then enters the broadcastclient mode, in which it listens for and synchronizes to succeeding broadcast messages. Note that, in order to avoid accidental or malicious disruption in this mode, both the local and remote servers must operate using authentication, and the same trusted key and key identifier.
This command directs the local server to listen for and respond to broadcast messages received on any local interface, and in addition enables the server to respond to client mode messages to the multicast group address(es) (type m) specified. At least one address is required, but The NTP multicast address 224.0.1.1 assigned by the IANA must not be used, unless specific means are taken to limit the span of the reply and avoid a possibly massive implosion at the original sender
This command directs the local server to listen for multicast messages at the group address(es) of the global network. The default address is that assigned by the Numbers Czar to NTP (224.0.1.1). This command operates in the same way as the broadcastclient command, but uses IP multicasting.
Authentication support enables the NTP client to verify that the server is in fact known and trusted and not an intruder impersonating that server. The NTPv3 specification RFC-1305 defines a scheme that provides cryptographic authentication of NTP packets received. In previous versions, this was done using the Data Encryption Standard (DES) operating in Cipher Block Chaining (CBC) mode, commonly called DES-CBC. Subsequently, this was augmented by the RSA Message Digest 5 (MD5) using a private key, commonly called keyed-MD5. Either algorithm computes a message digest, or one-way hash, that can be used to verify that the server has the correct private key and key identifier.
In the current implementation of NTP in ChorusOS, MD5 is the only method of authentication supported.
The authentication option specifies the suite of keys, selects the key for each configured association and manages the configuration operations, as described below. The auth flag which controls these functions can be set or reset by the enable and disable configuration commands. If this flag is set, persistent peer associations and remote configuration commands are effective only if cryptographically authenticated. If this flag is disabled, these operations are effective even if not cryptographic authenticated. Operating in the latter mode increases vulnerability as a hacker can seriously disrupt client timekeeping.
The original RFC-1305 specification allows any one of possibly 65,534 keys, each distinguished by a 32-bit key identifier, to authenticate an association. The servers involved must agree on the key and key identifier to authenticate their messages. Keys and related information are specified in a key file, usually called ntp.keys, which should be exchanged and stored using secure procedures beyond the scope of the NTP protocol itself. Besides the keys used for ordinary NTP associations, additional ones can be used as passwords for the ntpq utility program.
When ntpd is first started, it reads the key file and installs the keys in the key cache. However, the keys must be activated before they can be used with the trusted command. This provides a revocation capability that can be used if a key becomes compromised. The controlkey command selects the key used as the password for the ntpq utility.
The ntp.keys file contains the private MD5 keys. It must be distributed by secure means to other servers and clients sharing the same security compartment and made visible only to root.
The ntp.keys file contains 16 MD5 keys. Each key consists of 16 characters randomized over the ASCII 95-character printing subset. This file is read by the daemon at the location specified by the keys configuration file command and made visible only to root. An additional key consisting of an easily remembered password should be added by hand for use with the ntpq program. The file must be distributed by secure means to other servers and clients sharing the same security compartment. The key identifier for each association is specified as the key argument in the server or peer configuration file command.
In MD5 authentication, the keys are 64 bits (8 bytes). ntpd reads its keys from a file specified using the -k command line option or the keys statement in the configuration file. By default this file is /etc/ntp.keys. While key number 0 is fixed by the NTP standard (as 56 zero bits) and may not be changed, one or more of the keys numbered 1 through 15 may be arbitrarily set in the ntp.keys file.
The ntp.keys file uses the same comment conventions as the configuration file. Key entries use a fixed format of the form:
keyno type key |
The key is a 1-to-8 character ASCII string, using the MD5 authentication scheme. Note that both the keys and the authentication schemes must be identical between a set of peers sharing the same key number.
In the ntp.conf file, the keys line specifies the path to the keys file. The trustedkey declaration identifies those keys that are known to be uncompromised. Other keys that are specified are either expired or compromised keys. Both sets of keys must be declared by the key identifier in the ntp.keys file. This provides a way to retire old keys while minimizing the frequency of delicate key-distribution procedures. The requestkey line establishes the key to be used for mode-6 control messages as specified in RFC-1305 and used by the ntpq utility program. These keys are used to prevent unauthorized modification of daemon variables.
Ordinarily, the authentication delay; that is, the processing time taken between the freezing of a transmit timestamp and the actual transmission of the packet when authentication is enable. The delay can therefore be considered as the time it takes for the MD5 routine to encrypt a single block, and is computed automatically by the daemon. If necessary, the delay can be overridden by the authdelay line, which is used as a correction for the transmit timestamp.
The authdelay time is used to over-ride the delay added for authentication. This delay is computed by the daemon.
Specifies the key identifier to use with the ntpq program, which uses the standard protocol defined in RFC-1305. This program is useful to diagnose and repair problems that affect ntpd operation. The key argument to this command is a key identifier for a trusted key, where the value can be in the range 1 to 65534, inclusive.
Specifies the file name containing the private encryption keys and key identifiers used by ntpd and ntpq when operating in authenticated mode.
Specifies the encryption key identifiers which are trusted for the purposes of authenticating peers suitable for synchronization. The authentication procedures require that both the local and remote servers share the same key and key identifier, defined to be used for this purpose. However, different keys can be used with different servers. The arguments are 32 bit unsigned integers. Note, however, that key 0 is fixed and globally known. If meaningful authentication is to be performed, the 0 key should not be trusted.
ntpd includes a comprehensive monitoring facility suitable for continuous, long term recording of server and client timekeeping performance. See the statistics command below for a listing and example of each type of statistics currently supported.
Enables writing of statistics records. Currently, four kinds of name statistics are supported:
Enables recording of loop filter statistics information. Each update of the local clock outputs a line of the following form to the file generation set named loopstats:
50935 75440.031 0.000006019 13.778190 0.000351733 \ 0.013380 6 |
Description
The date (Modified Julian day)
The time (seconds and fraction past UTC midnight)
Time offset in seconds
Frequency offset in parts-per-million
RMS jitter in seconds
Allan deviation in parts-per-million
Clock discipline time constant
Enables recording of peer statistics information. This includes statistics records of all peers of an NTP server and of special signals, where present and configured. Each valid update appends a line of the following form to the current element of a file generation set named "peerstats":
48773 10847.650 127.127.4.1 9714 -0.001605 \ 0.00000 0.00142 |
Description
The date (Modified Julian Day)
The time (seconds and fraction past UTC midnight)
The peer address in dotted-quad notation
The peer status. The status field is encoded in hex in the format described in Appendix A of the NTP specification, RFC 1305.
Offset in seconds
Delay in seconds
RMS jitter in seconds
Enables recording of clock driver statistics information. Each update received from a clock driver outputs a line of the following form to the file generation set named "clockstats":
49213 525.624 127.127.4.1 93 226 \ 00:08:29.606 D |
Description
The date (Modified Julian Day)
The time (seconds and fraction past UTC midnight)
The clock address in dotted-quad notation
The last timecode received from the clock in decoded ASCII format, where meaningful
In some clock drivers, additional information can be gathered and displayed.
Enables recording of raw-timestamp statistics information. This includes statistics records of all peers of a NTP server and of special signals, where present and configured. Each NTP message received from a peer or clock driver appends a line of the following form to the file generation set named rawstats:
50928 2132.543 128.4.1.1 1284.1.20 3102353281.584327000 \ 3102453281.58622800031 02453332.540806000 3102453332.541458000 |
Description
The date (Modified Julian Day)
The time (seconds and fraction past UTC midnight)
The remote peer or clock address in dotted-quad notation
The local address in dotted-quad notation.
The originate NTP timestamp.
The receive NTP timestamp.
The transmit NTP timestamp.
The final NTP timestamp.
The timestamp values are as received and before processing by the various data smoothing and mitigation algorithms.
Indicates the full path of a directory where statistics files are created. This keyword allows the (otherwise constant) filegen filename prefix to be modified for file generation sets used to handle statistics logs.
Configures setting of generation file set name. Generation file sets provide a means for handling files that are continuously growing during the lifetime of a server. Server statistics are a typical example for such files. Generation file sets provide access to a set of files used to store the actual data. At any time at most one element of the set is being written to. The type given specifies when and how data will be directed to a new element of the set. In this way, information stored in elements of a file set that are currently unused are available for administration operations without the risk of disturbing the operation of ntpd. (Most important: they can be removed to free space for new data produced.)
This is the type of the statistics records, as shown in the statistics command.
This is the file name for the statistics records. Filenames of set members are built from three concatenated elements prefix, filename and suffix:
This is a constant filename path. It is not subject to modifications via the filegen statement. It is defined by the server, usually specified as a compile time constant. It may, however, be configurable for individual file generation sets via other commands. For example, the prefix used with loopstat and peerstats filegens can be configured using the statsdir statement explained above.
This string is directly concatenated to the prefix mentioned above (no intervening `/' (slash)). This can be modified using the file argument to the filegen statement. No `..' elements are allowed in this component to prevent filenames referring to parts outside the file system hierarchy denoted by prefix.
This part reflects individual elements of a file set. It is generated according to the type of a file set.
A file generation set is characterized by its type. The following types are supported:
none
The file set is actually a single plain file.
pid
One element of a file set is used per incarnation of a ntpd server. This type does not perform any changes to file set members during runtime. However it provides an easy way of separating files belonging to different ntpd server incarnations. The set member filename is built by appending a `.' (dot) to concatenated prefix and filename strings, and appending the decimal representation of the process id of the ntpd server process.
day
One file generation set element is created per day. The term day is based on UTC . A day is defined as the period between 00:00 and 24:00 UTC . The file set member suffix consists of a `.' (dot) and a day specification in the form, YYYYMMDD. YYYY is a 4 digit year number (e.g., 1992). MM is a two digit month number. DD is a two digit day number. All information written on December 10th, 1992 would end up in a file named, PrefixFilename.19921210.
week
Any file set member contains data related to a certain week of a year. The term week is defined by computing "day of year" modulo 7. Elements of such a file generation set are distinguished by appending the following suffix to the file set filename base: a dot, a four digit year number, the letter `W', and a two digit week number. For example, information from January, 5th 1992 would end up in a file with suffix ".1992W1".
month
One generation file set element is generated per month. The file name suffix consists of a dot, a four digit year number, and a two digit month.
year
One generation file element is generated per year. The filename suffix consists of a dot and a 4 digit year number.
age
This type of file generation sets changes to a new element of the file set every 24 hours of server operation. The filename suffix consists of a dot, the letter `a', and an eight digit number. This number is taken to be the number of seconds the server is running at the start of the corresponding 24 hour period. Information is only written to a file generation by specifying enable; output is prevented by specifying disable.
It is convenient to be able to access the current element of a file generation set by a fixed name. This feature is enabled by specifying link and disabled using nolink. If link is specified, a hard link from the current file set element to a file without suffix is created. When there is already a file with this name and the number of links of this file is one, it is renamed appending a dot, the letter C, and the pid of the ntpd server process. When the number of links is greater than one, the file is unlinked. This allows the current file to be accessed by a constant name.
Enables or disables the recording function.
ntpd implements a general purpose address-and-mask based restriction list. The list is sorted by address and by mask, and the list is searched in this order for matches, with the last match found defining the restriction flags associated with the incoming packets. The source address of incoming packets is used for the match, with the 32- bit address being and'ed with the mask associated with the restriction entry and then compared with the entry's address (which has also been and'ed with the mask) to look for a match.
The restriction facility was implemented in conformance with the access policies for the original NSFnet backbone time servers. While this facility may be otherwise useful for keeping unwanted or broken remote time servers from affecting your own, it should not be considered an alternative to the standard NTP authentication facility. Source address based restrictions are easily circumvented by a determined cracker.
numeric_address [ mask numeric_mask ] [ flag ] [ ... ]
The numeric_address argument, expressed in dotted- quad form, is the address of a host or network. The mask argument defaults to 255.255.255.255, meaning that the address is treated as the address of an individual host. A default entry (address 0.0.0.0, mask 0.0.0.0) is always included and, is always the first entry in the list. Note that, while address is normally given in dotted-quad format, the text string "default", with no mask option, may be used to indicate the default entry.
In the current implementation, flag always restrict access, i.e., an entry with no flags indicates that free access to the server is to be given. The flags are not orthogonal, in that more restrictive flags often make less restrictive ones redundant. The flags can generally be classed into two categories, those which restrict time service and those which restrict informational queries and attempts to do run time reconfiguration of the server.
One or more of the following flags may be specified:
Ignore all packets from hosts which match this entry. If this flag is specified neither queries nor time server polls will be responded to.
Ignore all NTP mode 6 and 7 packets (i.e., information queries and configuration requests) from the source. Time service is not affected.
Ignore all NTP mode 6 and 7 packets that attempt to modify the state of the server (such as run time reconfiguration). Queries which return information are permitted.
Decline to provide mode 6 control message trap service to matching hosts. The trap service is a subsystem of the mode 6 control message protocol which is intended for use by remote event logging programs.
Declare traps set by matching hosts to be low priority. The number of traps a server can maintain is limited. The current limit is 3. Traps are usually assigned on a first come, first served basis, with later trap requestors being denied service. This flag modifies the assignment algorithm by allowing low priority traps to be overridden by later requests for normal priority traps.
Ignore NTP packets with a mode other than 6 or 7. In effect, time service is denied, though queries may still be permitted.
Provide stateless time service to polling hosts, but do not allocate peer memory resources to these hosts even if they otherwise might be considered useful as future synchronization partners.
Treat these hosts normally in other respects, but never use them as synchronization sources.
These hosts are subject to a limitation on number of clients from the same net that will be accepted. Net in this context refers to the IP notion of net (class A, class B, class C, etc.). Only the first client_limit hosts that have shown up at the server and that have been active during the last client_limit_period seconds are accepted. Requests from other clients from the same net are rejected. Only time request packets are taken into account. Query packets sent by the ntpq program are not subject to these limits. A history of clients is kept using the monitoring capability of ntpd. Thus, monitoring is always active as long as there is a restriction entry with the limited flag.
This is actually a match algorithm modifier, rather than a restriction flag. Its presence causes the restriction entry to be matched only if the source port in the packet is the standard NTP UDP port (123). Both ntpport and non-ntpport may be specified. The ntpport flag is considered more specific and is sorted later in the list.
Default restriction list entries, with the flags, ignore, ntpport, for each of the local host's interface addresses are inserted into the table at startup to prevent the server from attempting to synchronize to its own time. A default entry is also always present, though if it is otherwise unconfigured no flags are associated with the default entry (i.e., everything besides your own NTP server is unrestricted).
Set the client_limit to limit variable, which limits the number of simultaneous access-controlled clients. The default value for this variable is 3.
Set the client_limit_period variable, which specifies the number of seconds after which a client is considered inactive and thus no longer is counted for client limit restriction. The default value for this variable is 3600 seconds.
The NTP Version 4 daemon supports many different radio, satellite and modem reference clocks plus a special pseudo-clock used for backup or when no other clock source is available.
A reference clock will generally (though not always) be a radio timecode receiver which is synchronized to a source of standard time such as the services offered by the NRC in Canada and NIST and USNO in the U.S. The interface between the computer and the timecode receiver is device dependent, but is usually a serial port.
NTP in ChorusOS uses the local clock of the operating system; an undisciplined local clock. This is the only clock driver supported.
For the purposes of configuration, ntpd treats reference clock in a manner analogous to normal NTP peers. The reference clock is identified by a syntactically correct but invalid IP address, in order to distinguish them from normal NTP peers. The reference clock's address is of the form 127.127.t.u, where t is an integer denoting the clock type and u indicates the unit number.
The only clock driver available on NTP in ChorusOS is the undisciplined local clock and the only value of t supported is 1. This driver is intended for use in an isolated network where no external source of synchronization such as a radio clock or modem is available. It allows a designated time server to act as a primary server to provide synchronization to other clients on the network. Pick a machine that has a good clock oscillator and configure it with this driver. Set the clock using the best means available, like eyeball-and-wristwatch. Then, point all the other machines at this one or use broadcast (not multicast) mode to distribute time.
Another application for this driver is if a particular server clock is to be used as the clock of last resort when all other normal synchronization sources have gone away. This is especially useful if that server has an ovenized oscillator. For this you would configure this driver at a stratum greater than any other likely sources of time (say 3 or 4) to prevent the server taking over when legitimate sources are still available.
The server command is used to configure the reference clock, where the address argument in that command is the clock address. The key, version and ttl options are not used for reference clock support. The prefer option can be used to get the server to favour the reference clock over other peers. To use the undisciplined clock driver, specify the address 127.127.1.u as a parameter of the server or fudge command.
The stratum number of a reference clock is by default zero. Since the ntpd daemon adds one to the stratum of each peer, a primary server ordinarily displays stratum one. In order to provide engineered backups, it is useful to specify the reference clock stratum as greater than zero. The stratum option is used for this purpose.
The undisciplined local clock supports the server and fudge commands:
127.127.1.u [ prefer ] |
Marks the reference clock as preferred. All other things being equal, this host will be chosen for synchronization among a set of correctly operating hosts.
127.127.1.u [ time1 time ] [ time2 time] [ stratum number ] [ refid string ] |
This command can be used to configure the reference clock in special ways. It must immediately follow the server command which configures the driver. The options are interpreted as follows:
Specifies the time offset calibration factor, in seconds and fraction, with default 0.0.
Specifies the frequency offset calibration factor, in parts per million, with default 0.0.
Specifies the driver stratum, in decimal from 0 to 15, with default 3.
Specifies the driver reference identifier, an ASCII string from one to four characters, with default LCL.
In the default mode the behavior of the clock selection algorithm is modified when this driver is in use. The algorithm is designed so that this driver will never be selected unless no other discipline source is available. This can be overridden with the prefer keyword of the server configuration command, in which case only this driver will be selected for synchronization and all other discipline sources are ignored.
Do not configure this driver to operate at a stratum which might disrupt a client with access to a bona fide primary server, unless the local clock oscillator is reliably disciplined by another source. Do not configure a server which might devolve to an undisciplined local clock to use multicast mode.
This driver provides a mechanism to trim the local clock in both time and frequency, as well as a way to manipulate the leap bits. The fudge time1 parameter adjusts the time (in seconds) and the fudge time2 parameter adjusts the frequency (in parts per million). Both parameters are additive and operate only once.
The broadcast and multicast modes require a special calibration to determine the network delay between the local and remote servers. Ordinarily, this is done automatically by the initial protocol exchanges between the client and server. In some cases, the calibration procedure may fail due to, for example, network or server access controls. This command specifies the default delay to be used under these circumstances. Typically (for Ethernet), a number between 0.003 and 0.007 is appropriate for seconds. When this command is not used, the default is 0.004 seconds.
This command specifies the name of the file used to record the frequency offset of the local clock oscillator. If the file exists, it is read at startup in order to set the initial frequency offset and then updated once per hour with the current frequency offset computed by the daemon. If the file does not exist or this command is not given, the initial frequency offset is assumed zero. In this case, it may take some hours for the frequency to stabilize and the residual timing errors to subside.
The file format consists of a single line containing a single floating point number, which records the frequency offset measured in parts-per-million (PPM). The file is updated by first writing the current drift value into a temporary file and then renaming this file to replace the old version. This implies that ntpd must have write permission for the directory the drift file is located in, and that file system links, symbolic or otherwise, should be avoided.
Provides a way to enable or disable various server options. Flags not mentioned are unaffected.
Enables the server to synchronize with unconfigured peers only if the peer has been correctly authenticated using a trusted key and key identifier. The default for this flag is enable.
When enabled, this is identical to the broadcastclient command. The default for this flag is disable.
Enables the monitoring facility. The default for this flag is enable.
Enables the server to adjust its local clock by means of NTP. If disabled, the local clock free-runs at its intrinsic time and frequency offset. This flag is useful in case the local clock is controlled by some other device or protocol and NTP is used only to provide synchronization to other clients. In this case, the local clock driver can be used to provide this function and also certain time variables for error estimates and leap-indicators. The default for this flag is enable.
Enables the statistics facility. The default for this flag is enable.
This command controls the amount and type of output written to the system sysLog facility or the alternate logfile log file. By default, all output is turned on. All configkeyword keywords can be prefixed with =, + and -, where = sets the syslogmask, + adds and - removes messages. sysLog messages can be controlled in four classes (sys, peer, sys and sync). Within these classes four types of messages can be controlled.
Informational messages (info) control configuration information. Event messages (events) control logging of events (reachability, synchronization, alarm conditions). Statistical output is controlled with the statistics keyword. The final message group is the status messages. This describes mainly the synchronizations status. Configuration keywords are formed by concatenating the message class with the event class. The all prefix can be used instead of a message class. A message class may also be followed by the all keyword to enable/disable all messages of the respective message class. Thus, a minimal log configuration looks like this:
logconfig = syncstatus +sysevents |
This lists the synchronizations state of ntpd and the major system events. For a simple reference server, the following minimum message configuration could be useful:
logconfig = syncall +clockall |
This configuration will list all clock information and synchronization information. All other events and messages about peers, system events and so on is suppressed.
This command specifies the location of an alternate log file to be used instead of the default system sysLog facility.
This command adds an additional system variable. These variables can be used to distribute additional information such as the access policy. If the variable of the form, variable_name=value is followed by the default keyword, the variable will be listed as one of the default system variables (see the ntpq command). Additional variables serve informational purposes only. They can be listed; but they are not related to the protocol. The known protocol variables always override any variables defined via the setvar mechanism.
Three special variables contain the names of all variable of the same group. sys_var_list holds the names of all system variables. peer_var_list holds the names of all peer variables. And clock_var_list hold the names of the reference clock variables.
This command configures a trap receiver at the given host address and port number for sending messages with the specified local interface address. If the port number is unspecified. a value of 18447 is used. If the interface address is not specified, the message is sent with a source address of the local interface the message is sent through. Note that on a multihomed host the interface used may vary from time to time with routing changes.
The trap receiver will log event messages and other information from the server in a log file. While such monitor programs can also request their own trap dynamically, configuring a trap receiver will ensure that no messages are lost when the server is started.
Default name of the configuration file
Conventional name of the drift file
Conventional name of the key file
Sample server configuration file
Sample client configuration file
See attributes(5) for descriptions of the following attributes:
ATTRIBUTE TYPE | ATTRIBUTE VALUE |
---|---|
Interface Stablility | Evolving |
The version of NTP incorporated in ChorusOS is ntp-4.0.99i.
This distribution does not include ntpdc
. Note,
however, that previous versions of ntpdc
do not work
with the version of ntpd
.
NAME | SYNOPSIS | DESCRIPTION | OPTIONS | USAGE | FILES | ATTRIBUTES | SEE ALSO | NOTES