The ntpd program is an operating system daemon that synchronises the system clock with remote NTP time servers or local reference clocks. It is a complete implementation of the Network Time Protocol (NTP) version 4, but 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. The program can operate in any of several modes, as described on the Association Management page, and with both symmetric key and public key cryptography, as described on the Authentication Options page.
+-The ntpd program ordinarily requires a configuration file as desccribe on the Configuration Commands and Options collection above. However a client can discover remote servers and configure them automatically. This makes it possible to deploy a fleet of workstations without specifying configuration details specific to the local environment. Further details are on the Automatic Server Discovery page.
++The ntpd program ordinarily requires a configuration file as described on the Configuration Commands and Options collection above. However a client can discover remote servers and configure them automatically. This makes it possible to deploy a fleet of workstations without specifying configuration details specific to the local environment. Further details are on the Automatic Server Discovery page.
+Once the NTP software distribution has been compiled and installed and the configuration file constructed, the next step is to verify correct operation and fix any bugs that may result. Usually, the command line that starts the daemon is included in the system startup file, so it is executed only at system boot time; however, the daemon can be stopped and restarted from root at any time. Once started, the daemon will begin sending and receiving messages, as specified in the configuration file.
+The ntpd program operates by exchanging messages with one or more servers at designated intervals ranging from about one minute to about 17 minutes. When started, the program requires several exchanges while the algorithms accumulate and groom the data before setting the clock. The initial delay to set the clock can be reduced using options on the Server Options page.
+-Most compters today incorporate a time-of-year (TOY) chip to maintain the time during periods when the power is off. When the machine is booted, the chip is used to initialize the operating system time. In case there is no TOY chip or the TOY time is more than 1000 s from the server time, ntpd assumes something must be terribly wrong and exits with a panic message to the system operator. With the -g option the clock will be initially set to the server time regardless of the chip time. However, once the clock has been set, an error greater than 1000 s will cause ntpd to exit anyway.
++Most computers today incorporate a time-of-year (TOY) chip to maintain the time during periods when the power is off. When the machine is booted, the chip is used to initialize the operating system time. In case there is no TOY chip or the TOY time is more than 1000 s from the server time, ntpd assumes something must be terribly wrong and exits with a panic message to the system operator. With the -g option the clock will be initially set to the server time regardless of the chip time. However, once the clock has been set, an error greater than 1000 s will cause ntpd to exit anyway.
+Under ordinary conditions, ntpd slews the clock so that the time is effectively continuous and never runs backwards. If due to extreme network congestion an error spike exceeds the step threshold, by default 128 ms, the spike is discarded. However, if the error persists for more than the stepout threshold, by default 900 s, the system clock is stepped to the correct value. In practice the need for a step has is extremely rare and almost always the result of a hardware failure. With the -x option the step threshold is increased to 600 s. Other options are available using the tinker command on the Miscellaneous Options page.
+The issues should be carefully considered before using these options. The maximum slew rate possible is limited to 500 parts-per-million (PPM) by the Unix kernel. As a result, the clock can take 2000 s for each second the clock is outside the acceptable range. During this interval the clock will not be consistent with any other network clock and the system cannot be used for distributed applications that require correctly synchronized network time.
+The frequency file, usually called ntp.drift, contains the latest estimate of clock frequency. If this file does not exist when ntpd is started, it enters a special mode designed to measure the particular frequency directly. The measurement takes 15 minutes, after which the frequency is set and ntpd resumes normal mode where the time and frequency are continuously adjusted. The frequency file is updated at intervals of an hour or more depending on the measured clock stability.
+@@ -70,7 +70,7 @@ + tally the leap warning bits of surviving servers and reference clocks. + When a majority of the survivors show warning, a leap is programmed + at the end of the current month. During the month and day of insertion, +- they operate as above. In this way the leap is is propagated at all ++ they operate as above. In this way the leap is propagated at all + dependent servers and clients. +A new experimental feature called interleaved modes can be used in NTP @@ -143,26 +143,8 @@
The ntpd program is an operating system daemon that synchronises the system clock with remote NTP time servers or local reference clocks. It is a complete implementation of the Network Time Protocol (NTP) version 4, but 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. The program can operate in any of several modes, as described on the Association Management page, and with both symmetric key and public key cryptography, as described on the Authentication Options page.
-The ntpd program ordinarily requires a configuration file as desccribe on the Configuration Commands and Options collection above. However a client can discover remote servers and configure them automatically. This makes it possible to deploy a fleet of workstations without specifying configuration details specific to the local environment. Further details are on the Automatic Server Discovery page.
+The ntpd program ordinarily requires a configuration file as described on the Configuration Commands and Options collection above. However a client can discover remote servers and configure them automatically. This makes it possible to deploy a fleet of workstations without specifying configuration details specific to the local environment. Further details are on the Automatic Server Discovery page.
@@ -123,6 +123,8 @@This driver receives its reference clock info from a shared memory-segment. The shared memory-segment is created with owner-only access for unit 0 and 1, and world access for unit 2 and 3
++This driver receives its reference clock info from a shared memory-segment. The shared memory-segment is created with owner-only access for unit 0 and 1, and world access for other units unless the mode word is set for owner-only access.
++ + +struct shmTime {
+@@ -94,6 +95,40 @@ Here is a sample showing the GPS recepti
+ 54364 85700.160 127.127.28.0 65 0 65 0 0
+
+
++
++ Some aspects of the driver behavior can be adjusted by setting bits of
++ the 'mode' word in the server configuration line:
++ server 127.127.28.x mode Y
++
| Bit | ++Dec | ++Hex | ++Meaning | ++
|---|---|---|---|
| 0 | ++1 | ++1 | ++The SHM segment is private (mode 0600). This is the fixed ++ default for clock units 0 and 1; clock units >1 are mode ++ 0666 unless this bit is set for the specific unit. | ++ ++
| 1-31 | ++- | ++- | ++reserved -- do not use | ++
The driver attempts to create a shared memory segment with an ++ identifier depending on the unit number. This identifier (which can be ++ a numeric value or a string) clearly depends on the method used, which ++ in turn depends on the host operating system:
++ ++++ Windows uses a file mapping to the page file with the ++ name 'Global\NTPu' for public accessible ++ mappings, where u is the clock unit. Private / ++ non-public mappings are created as ++ 'Local\NTPu'. ++
++ Public access assigns a NULL DACL to the memory mapping, while ++ private access just uses the default DACL of the process creating ++ the mapping. ++
++++ SYSV IPC creates a shared memory segment with a key value ++ of 0x4E545030 + u, where u is again ++ the clock unit. (This value could be hex-decoded as 'NTP0', ++ 'NTP1',..., with funny characters for units > 9.) ++
++ Public access means a permission set of 0666, while private access ++ creates the mapping with a permission set of 0600. ++
++There's no support for POSIX shared memory yet.
++ ++NTPD is started as root on most POSIX-like operating systems ++ and uses the setuid/setgid system API to run under reduced rights once ++ the initial setup of the process is done. One consequence out of this ++ is that the allocation of SHM segments must be done early during the ++ clock setup. The actual polling of the clock is done as the run-time ++ user; deferring the creation of the SHM segment to this point will ++ create a SHM segment owned by the runtime-user account. The internal ++ structure of NTPD does not permit the use of a fudge flag if ++ this is to be avoided; this is the reason why a mode bit is used for ++ the configuration of a public segment. ++
++ ++When running under Windows, the chosen user account must be able to ++ create a SHM segment in the global object name space for SHM clocks with ++ public access. Otherwise the session isolation used by Windows kernels ++ after WinXP will get into the way if the client program does not run in ++ the same session. ++
++ ++