![[Previous]](../prev.gif) |
![[Contents]](../contents.gif) |
![[Index]](../keyword_index.gif) |
![[Next]](../next.gif) |
|
|
|
|
Network Time Protocol (NTP) daemon
ntpd [-46aAbdgLmnNpqx] [-c conffile] [-D level]
[-f driftfile] [-i jaildir]
[-k keyfile] [-l logfile] [-p pidfile]
[-P priority] [-r broadcastdelay]
[-s statsdir] [-t key]
[-u user[:group] ] [-v variable] [-V variable]
Use the ntpd utility to set and maintain the system time of day in synchronism with the Internet standard time servers. This utility is an operating system daemon that conforms to the NTP (Network Time Protocol) version 4 specification. It also retains compatibility with version 3, as defined by RFC 1305, and version 1 and 2, as defined by RFC 1059 and RFC 1119. Using the 64-bit floating point arithmetic, the ntpd utility attempts to preserve the ultimate precision, which is about 232 picoseconds. While the ultimate precision is not achievable with today's workstations and networks, it is required for future gigahertz CPU clocks and gigabit LANs.
The ntpd utility exchanges messages with one or more configured hosts at designated poll intervals. This is done to groom data and set the clock. Although the default initial poll interval is 64 seconds, the poll interval for each server is delayed by an interval randomized over few seconds. It is done to protect the network from bursts.
In order to maintain time during periods when the power is off, today's hardware incorporate a time-of-year (TOY) chip. When the machine is booted, the chip is used to initialize the operating system time. After the machine has synchronized to a NTP server, the operating system corrects the chip from time to time.
Under ordinary condition, the ntpd utility adjusts the clock in small steps so that the time scale is continuous. Under conditions of extreme network congestion, the ntpd algorithms discard sample offsets exceeding 128 ms, because:
When there is no TOY chip, and the client time is more than 1000 seconds from the server time, you should intervene and set the clock by hand -- causing the ntpd utility to exit with a panic message to the system log.
Behavior of the ntpd utility at startup depends on the existence of ntp.draft frequency file. This file contains the latest estimate of the clock frequency error. If this file doesn't exist, the ntpd utility enters a special mode designed to quickly adapt to system clock oscillator time and frequency error. After approximately 15 minutes, when the time and frequency are set to nominal values, the ntpd utility starts tracking the time and frequency relative to the server. After one hour, the current frequency offset is written to ntp.draft frequency file. Since the ntpd frequency is initialized from this file, the ntpd utility enters into normal mode immediately during startup. Subsequently, the current frequency offset is written to the ntp.draft frequency file at hourly intervals.
The ntpd utility operates continuously while monitoring for small changes in frequency, trimming the clock for ultimate precision. It operates in one of several modes:
The ntpd utility also operates in one-time mode where the time is set from an external server, and the frequency is set from a previously recorded frequency file. When a client operates in broadcast/multicast or manycast mode, it first discovers the remote server, and then configures itself automatically -- after computing the server-client propagation delay correction factors. You can now deploy a fleet of workstations without specifying configuration details that are specific to your local environment.
When the ntpd utility runs in continuous mode, each of the external servers is polled at intervals determined by an intricate state machine. The state machine determines the poll interval using a heuristic algorithm, after measuring the incidental roundtrip delay jitter and oscillator frequency wander. In most operating environments, the state machine starts with 64 seconds intervals that increase to 1024 seconds, in steps. A small amount of random variation is also introduced in order to avoid bunching at the servers.
In some cases, it may not be practical for ntpd to run continuously. A common workaround has been to run the ntpdate utility from a cron job at designated times. This utility, however, doesn't have the signal processing, error checking, and mitigation algorithms of the ntpd utility. The -q option is intended for this purpose.
In QNX Neutrino, an useful feature is available to discipline the clock frequency. First, the ntpd utility is run in continuous mode with selected servers in order to measure and record the intrinsic clock frequency offset. This may take hours (for the frequency and offset) to settle down. Then the ntpd utility is stopped and run in one-time mode as required. At each startup, ntpd reads the frequency from the file and initializes the kernel frequency.
The state machine for ntpd maintains synchronization consistent with the observed jitter and wander. You now have several ways to tailor the operation of the ntpd utility, for example, either by reducing or increasing the poll interval. You must be careful, however, to consider the consequences of changing the adjustment range for poll intervals.
 |
The default minimum for poll interval is 64 seconds, and the default maximum is 1,024 seconds. |
You can change the default minimum with the tinker minpoll command to a value not less than 16 seconds. This value is used for all configured associations, unless overridden by the minpoll option on the configuration command. Most of the device drivers don't operate properly if the poll interval is less than 64 seconds.
In some cases involving dialup or toll services, you may also increase the minimum interval to a few tens of minutes and the maximum interval to a day or so. Under normal operating conditions, once the clock discipline loop has stabilized, the interval is increased in steps from the minimum to the maximum value. This assumes, however, that the intrinsic clock frequency error is small enough for the discipline loop to correct it. The capture range of the loop is 500 PPM at an interval of 64 seconds, decreasing by a factor of two for each doubling of interval. At a minimum of 1,024 seconds, for example, the capture range is only 31 PPM. If the intrinsic error is greater than this, the ntp.drift drift file is specially tailored to reduce the residual error below this limit. Once this is done, the drift file is automatically updated once every hour and is available to initialize the frequency on subsequent daemon restarts.
Timekeeping quality may seriously degrade in certain scenarios, for example, when a considerable amount of data is to be downloaded or uploaded over telephone modems. This occurs because differential delays during transmission on two directions can be quite large. Sometimes, time errors even exceed the step threshold, resulting in step correction during and after the data transfer.
Use the huff-n'-puff filter to correct the time offset in these cases. It uses the knowledge of the propagation delay when no other traffic is present, i.e. during other than work hours. The filter maintains a shift register that remembers the minimum delay over the most recent interval that is measured in hours. Under conditions of severe delay, the filter corrects the apparent offset using the sign of the offset, and the difference between the apparent delay and minimum delay. The name of the filter reflects the negative (huff) and positive (puff) correction, which depends on the sign of the offset. The filter is activated by the tinker command and huffpuff keyword.
ntpdate, ntpdc, ntpq, ntptrace
RFC 1059, RFC 1119, RFC 1305
|
|
|
|