Vista ntpd

Under ordinary conditions, ntpd adjusts the clock in small steps so that the timescale is effectively continuous and without discontinuities. Under conditions of extreme network congestion, the roundtrip delay jitter can exceed three seconds and the synchronization distance, which is equal to one-half the roundtrip delay plus error budget terms, can become very large.

The ntpd algorithms discard sample offsets exceeding ms, unless the interval during which no sample offset is less than ms exceeds s. The first sample after that, no matter what the offset, steps the clock to the indicated time. In practice this reduces the false alarm rate where the clock is stepped in error to a vanishingly low incidence. As the result of this behavior, once the clock has been set, it very rarely strays more than ms, even under extreme cases of network path congestion and jitter.

Sometimes, in particular when ntpd is first started, the error might exceed ms. This may on occasion cause the clock to be set backwards if the local clock time is more than s in the future relative to the server. In some applications, this behavior may be unacceptable. If the -x option is included on the command line, the clock will never be stepped and only slew corrections will be used.

The issues should be carefully explored before deciding to use the -x option. The maximum slew rate possible is limited to parts-per-million PPM as a consequence of the correctness principles on which the NTP protocol and algorithm design are based.

As a result, the local clock can take a long time to converge to an acceptable offset, about 2, s for each second the clock is outside the acceptable range. During this interval the local 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.

In spite of the above precautions, sometimes when large frequency errors are present the resulting time offsets stray outside the ms range and an eventual step or slew time correction is required. If following such a correction the frequency error is so large that the first sample is outside the acceptable range, ntpd enters the same state as when the ntp. The intent of this behavior is to quickly correct the frequency and restore operation to the normal tracking mode. In the most extreme cases time.

It helps in these cases to use the burst keyword when configuring the server. The ntpd behavior at startup depends on whether the frequency file, usually ntp. This file contains the latest estimate of clock frequency error. When the ntpd is started and the file does not exist, the ntpd enters a special mode designed to quickly adapt to the particular system clock oscillator time and frequency error.

This takes approximately 15 minutes, after which the time and frequency are set to nominal values and the ntpd enters normal mode, where the time and frequency are continuously tracked relative to the server.

After one hour the frequency file is created and the current frequency offset written to it. When the ntpd is started and the file does exist, the ntpd frequency is initialized from the file and enters normal mode immediately.

After that the current frequency offset is written to the file at hourly intervals. It normally operates continuously while monitoring for small changes in frequency and trimming the clock for the ultimate precision. However, it can operate in a one-time mode where the time is set from an external server and frequency is set from a previously recorded frequency file.

This makes it possible to deploy a fleet of workstations without specifying configuration details specific to the local environment. By default, ntpd runs in continuous mode where each of possibly several external servers is polled at intervals determined by an intricate state machine. The state machine measures the incidental roundtrip delay jitter and oscillator frequency wander and determines the best poll interval using a heuristic algorithm. Ordinarily, and in most operating environments, the state machine will start with 64s intervals and eventually increase in steps to s.

A small amount of random variation is introduced in order to avoid bunching at the servers. In addition, should a server become unreachable for some time, the poll interval is increased in steps to s in order to reduce network overhead.

In some cases it may not be practical for ntpd to run continuously. A common workaround has been to run the ntpdate program from a cron job at designated times. However, this program does not have the crafted signal processing, error checking and mitigation algorithms of ntpd.

The -q option is intended for this purpose. Setting this option will cause ntpd to exit just after setting the clock for the first time. The procedure for initially setting the clock is the same as in continuous mode; most applications will probably want to specify the iburst keyword with the server configuration command. With this keyword a volley of messages are exchanged to groom the data and the clock is set in about 10 s. If nothing is heard after a couple of minutes, the daemon times out and exits.

Starting with Windows Vista the real timer tick was obviously decreased from about 16 ms to 1 ms. This is also the resolution which you can get with the callback function mentioned above, so current versions of ntpd don't use the extrapolation feature the program determines that the time increments in 1 ms steps or less. This means if the time synchronization software makes small time adjustments to slew the system time smoothly then this has no effect at all.

As a consequence the control loop in ntpd could get unstable. Current versions of ntpd namely 4. This call also returns a FILETIME structure, but should really return time stamps with ns resolution, so time differences against refclocks or time stamps in NTP packets can be computed much more precisely.

If you distribute a precompiled binary for Windows then you don't know on which Windows version the executable will finally be run, so ntpd checks at startup if this new API call is supported, and uses it, and otherwise falls back to using the legacy function. Even in Windows 10 there is still no leap second support in the Windows kernel, so ntpd has another built-in workaround to handle this.

Export to PDF Back to top. Microsoft Windows 4. Configuring PPS Support 4. The following software is used when installing NTP source code: A C compiler make note that on some platforms, building outside of the main source directory requires GNU make.

There is a "Search" box on the top right-hand-side of the window. Send an email to questions lists. NTP Pool Client apt-get install ntp 4. In addition there was a serialpps-ppsapi-provider.

Many more hints on using this driver can be found on David J. Taylor's web page These days PCs and laptops often don't provide a real serial port with a physical UART chip, so eventually this approach can't be used on these machines. The PPS Hack To work around the problem that there is no physical UART chip there has been something in ntpd that was known alas, not widely known as the PPS hack : Since ntpd anyway had to monitor the serial line for what WIndows calls COMM events, it also checked for level changes of the DCD line and used the time stamp of this change to supplant the receive time stamp for the next line of text.

This works in user mode and needs no special driver, and it works for every serial interface known to Windows, but it gives reliable results only under tight constraints. Whether the PPS Hack is to be used, or not, could be configured via an environment variable. A kernel mode driver can but not necessarily will provide time stamps with less jitter than any user mode application, but loopback-ppsapi-provider.

In case you wonder about the name: This provider loops back into ntpd to tap into information already there.