Access Control Options

Record the time of day and offset displayed by the ntpq pe command. Wait for an hour or so and record the time of day and offset. Calculate the frequency as the offset difference divided by the time difference. If the frequency is much above 100 PPM, the tickadj program might be useful to adjust the kernel clock frequency below that value. For systems that do not support this program, this might be one using a command in the system startup file.

Access Controls

Provisions are included in ntpd for access controls which deflect unwanted traffic from selected hosts or networks. The controls described on the Access Control Options include detailed packet filter operations based on source address and address mask. Normally, filtered packets are dropped without notice other than to increment tally counters. However, the server can be configured to send a "kiss-o'-death" (KOD) packet to the client either when explicitly configured or when cryptographic authentication fails for some reason. The client association is permanently disabled, the access denied bit (TEST4) is set in the flash variable and a message is sent to the system log.

The access control provisions include a limit on the packet rate from a host or network. If an incoming packet exceeds the limit, it is dropped and a KOD sent to the source. If this occurs after the client association has synchronized, the association is not disabled, but a message is sent to the system log. See the Access Control Options page for further informatin.

The access control provisions include a limit on the packet rate from a + host or network. If an incoming packet exceeds the limit, it is dropped and + a KOD sent to the source. If this occurs after the client association has + synchronized, the association is not disabled, but a message is sent to the + system log. See the Access Control Options page + for further information.

Large Delay Variations

In some reported scenarios an access line may show low to moderate network delays during some period of the day and moderate to high delays during other periods. Often the delay on one direction of transmission dominates, which can result in large time offset errors, sometimes in the range up to a few seconds. It is not usually convenient to run ntpd throughout the day in such scenarios, since this could result in several time steps, especially if the condition persists for greater than the stepout threshold.

Specific provisions have been built into ntpd to cope with these problems. The scheme is called "huff-'n-puff and is described on the Miscellaneous Options page. An alternative approach in such scenarios is first to calibrate the local clock frequency error by running ntpd in continuous mode during the quiet interval and let it write the frequency to the ntp.drift file. Then, run ntpd -q from a cron job each day at some time in the quiet interval. In systems with the nanokernel or microkernel performance enhancements, including Solaris, Tru64, Linux and FreeBSD, the kernel continuously disciplines the frequency so that the residual correction produced by ntpd is usually less than a few milliseconds.

This page lists the status words, event messages and error codes used for ntpd reporting and monitoring. Status words are used to display the current status of the running program. There is one system status word and a peer status word for each association. There is a clock status word for each association that supports a reference clock. There is a flash code for each association which shows errors found in the last packet received (pkt) and during protocol processing (peer). These are commonly viewed using the ntpq program.

Significant changes in program state are reported as events. There is one set of system events and a set of peer events for each association. In adition, there is a set of clock events for each association that supports a reference clock. Events are normally reported to the protostats monitoring file and optionally to the system log. In addition, if the trap facility is configured, events can be reported to a remote program that can page an administrator.

Significant changes in program state are reported as events. There is one + set of system events and a set of peer events for each association. In addition, + there is a set of clock events for each association that supports a reference + clock. Events are normally reported to the protostats monitoring file + and optionally to the system log. In addition, if the trap facility is configured, + events can be reported to a remote program that can page an administrator.

This page also includes a description of the error messages produced by the Autokey protocol. These messages are normally sent to the cryptostats monitoring file.

Clock Status Word

The clock status word consists of four fields: Unused (0-7), Count (8-11) and Code (12-15). It is reported in the first line of the clockvar associd display produced by the ntpq program.

External Clock Discipline and the Local Clock Driver

The NTPv4 implementation includes provisions for an external clock, where the system clock is implemented by some external hardware device. One implementation might take the form of a bus peripheral with a high resolution counter disciplined by a GPS receiver, for example. Another implementation might involve another synchronization protocol, such as the Digital Time Synchronization Service (DTSS), where the system time is disciplined to this protocol and NTP clients of the server obtain synchronization indirectly via the server. A third implementation might be a completely separate clock discipline algorithm and synchronization protocol, such as the Lockclock algorithm used with NIST Automated Computer Time Service (ACTS) modem synchronized time.

The NTPv4 implementation includes provisions for an external clock, where + the system clock is implemented by some external hardware device. + One implementation might take the form of a bus peripheral with a high resolution + counter disciplined by a GPS receiver, for example. Another implementation + might involve another synchronization protocol, such as the Digital Time Synchronization + Service (DTSS), where the system time is disciplined to this protocol and + NTP clients of the server obtain synchronization indirectly via the server. + A third implementation might be a completely separate clock discipline algorithm + and synchronization protocol, such as the Lockclock algorithm used + with NIST Automated Computer Time Service (ACTS) modem synchronized time.

When external clocks are used in conjunction with NTP service, some way needs to be provided for the external clock driver and NTP daemon ntpd to communicate and determine which discipline is in control. This is necessary in order to provide backup, for instance if the external clock or protocol were to fail and synchronization service fall back to other means, such as a local reference clock or another NTP server. In addition, when the external clock and driver are in control, some means needs to be provided for the clock driver to pass on status information and error statistics to the NTP daemon.

Control and monitoring functions for the external clock and driver are implemented using the Local Clock (type 1) driver and the ntp_adjtime() system call. This system call is implemented by special kernel provisions included in the kernel of several operating systems, including Solaris, Tru64, FreeBSD and Linux, and possibly others. When the external clock is disabled or not implemented, the system call is used to pass time and frequency information, as well as error statistics, to the kernel. Besides disciplining the system time, the same interface can be used by other applications to determine the operating parameters of the discipline.

When the external clock is enabled, ntpd does not discipline the system clock, nor does it maintain the error statistics. In this case, the external clock and driver do this using mechanisms unknown to ntpd; however, in this case the kernel state variables are retrieved at 64-s intervals by the Local Clock driver and used by the clock selection and mitigation algorithms to determine the system variables presented to other NTP clients and peers. In this way, downstream clients and servers in the NTP subnet can make an intelligent choice when more than one server is available.

In order to implement a reliable mitigation between ordinary NTP sources and the external clock source, a protocol is necessary between the local clock driver and the external clock driver. This is implemented using Boolean variables and certain bits in the kernel clock status word. The Boolean variables include the following:

ntp_enable. set/reset by the enable command. enables ntpd + clock discipline

If the kern_enable switch is set, the daemon computes the offset, frequency, maximum error, estimated error, time constand and status bits, then provides them to the kernel via ntp_adjtime(). If this switch is not set, these values are not passed to the kernel; however, the daemon retrieves their present values and uses them in place of the values computed by the daemon.

If the kern_enable switch is set, the daemon computes the offset, + frequency, maximum error, estimated error, time constant and status bits, + then provides them to the kernel via ntp_adjtime(). If this switch + is not set, these values are not passed to the kernel; however, the daemon + retrieves their present values and uses them in place of the values computed + by the daemon.

The pps_update bit set in the protocol routine if the prefer peer has survived and has offset less than 128 ms; otherwise set to zero.

The pps_control Updated to the current time by kernel support if the PPS signal is enabled and working correctly. Set to zero in the adjust routine if the interval since the last update exceeds 120 s.

The PPS control Updated to the current time by kernel support if + the PPS signal is enabled and working correctly. Set to zero in the adjust + routine if the interval since the last update exceeds 120 s.

The ntp_enable and kern_enable are set by the configuration module. Normally, both switches default on, so the daemon can control the time and the kernel discipline can be used, if available. The pps_update switch is set by the protocol module when it believes the PPS provider source is legitimate and operating within nominals. The ntp_control switch is set during configuration by interrogating the kernel. If both the kern_enable and ntp_control switches are set, the daemon disciplines the clock via the kernel and the internal daemon discipline is disabled.

The external clock driver controls the system time and clock selection in the following way. Normally, the driver adjusts the kernel time using the ntp_adjtime() system call in the same way as the daemon. In the case where the kernel discipline is to be used intact, the clock offset is provided in this call and the loop operates as specified. In the case where the driver steers only the frequency, the offset is specified as zero.

Introduction

Many radio clocks used as a primary reference source for NTP servers produce a pulse-per-second (PPS) signal that can be used to improve accuracy to a high degree. However, the signals produced are usually incompatible with the modem interface signals on the serial ports used to connect the signal to the host. The gadget box consists of a handful of electronic components assembled in a small aluminum box. It includes level converters and a optional radio modem designed to decode the radio timecode signals transmitted by the Canadian time and frequency station CHU. A complete set of schematics, PCB artwork, drill templates can be obrtained via the web from ftp.udel.edu as gadget.tar.Z.

Many radio clocks used as a primary reference source for NTP servers produce + a pulse-per-second (PPS) signal that can be used to improve accuracy to a + high degree. However, the signals produced are usually incompatible with the + modem interface signals on the serial ports used to connect the signal to + the host. The gadget box consists of a handful of electronic components assembled + in a small aluminum box. It includes level converters and a optional radio + modem designed to decode the radio timecode signals transmitted by the Canadian + time and frequency station CHU. A complete set of schematics, PCB artwork, + drill templates can be obtained via the web from ftp.udel.edu as gadget.tar.Z.

The gadget box is assembled in a 5"x3"x2" aluminum minibox containing the level converter and modem circuitry. It includes two subcircuits. One of these converts a TTL positive edge into a fixed-width pulse at EIA levels and is for use with a timecode receiver or oscillator including a TTL PPS output. The other converts the timecode modulation broadcast by Canadian time/frequency standard station CHU into a 300-bps serial character stream at EIA levels and is for use with the Radio CHU Audio Demodulator/Decoder driver.

Resolving Problems

Like other things in modern Internet life, NTP problems can be devilishly intricate. This distribution includes a number of utilities designed to identify and repair problems using an integrated management protocol supported by the ntpq utility program In addition, the ntpdc utility program can be useful in some cases.

The NTP Debugging Techniques and Hints and Kinks pages contain useful information for identifying problems and devising solutions. Additional information on reference clock driver construction and debugging is in the Debugging Hints for Reference Clock Drivers page.

diff --git a/html/manyopt.html b/html/manyopt.html index 5928d49473..ea50a7e89a 100644 --- a/html/manyopt.html +++ b/html/manyopt.html @@ -51,7 +51,11 @@

The use of cryptograpic authentication is always a good idea in any server descovery scheme. Both symmetric key and public key cryptography can be used in the same scenarios as described above for the broadast/multicast scheme.

Server Pool Scheme

The idea of targeting servers on a random basis to distribute and balance the load is not a new one; however, the NTP pool scheme puts this on steroids. At present, several hundred operators around the globe have volunteered their servers for public access. In general, NTP is a lightweight service and servers used for other purposes don't mind an additional small load. The trick is to randomize over the population and minimize the load on any one server while retaining the advantages of multiple servers using the NTP mitigation algorithms.

To support this service the DNS for some volunteer servers as been modified to collect a number of other volunteer servers and return a randomized list in response to a DNS query. The client receiving this list modbilizes some or all of them just as in the other discovery schemes and casts off the excess.

To support this service the DNS for some volunteer servers as been + modified to collect a number of other volunteer servers and return a + randomized list in response to a DNS query. The client receiving this list + mobilizes some or all of them just as in the other discovery schemes and casts + off the excess.

The pool scheme is configured using one or pool commands with the DNS name region.pool.ntp.org, where region is a region of the world, country of the region or state of the country or even the whole world if absent. The pool command can be used more than once; duplicate servers are detected and discarded. In principle, it is possible to use a configuration file containing a single line pool pool.ntp.org.

Access Control Support

Symmetric Active/Passive Mode

Sound Card Drivers

Setup and Debugging Aids

Public Key Cryptography

Non-Security Bug Reporting Procedures

Verifying Correct Operation