However, there are only some specific cases where this should be limited by configuration, e.g. Normally it's a good idea to let ntpd itself adjust the polling intervals for its time sources. The default range for the polling interval is 2^6s = 64s up to 2^10s = 1024s. The polling interval is adjusted automatically by ntpd depending on the stability of the local system clock. Ntpd has very powerful adaptive filters to determine the mean packet delay, network jitter, its own time offset,Īnd how the time offset evolves, i.e. This is why ntpd always evaluates the results from several polling actions over several polling intervals before it starts adjusting its own system time. So jitter reduces the accuracy of the computed time offset, and some filtering is required to reduce the jitter as good as possible.
It is not clear if this is really a time offset, or it just looks like a time offset because a network packet has been queued in a switch or router. So a small time offset from a GPS receiver can quickly be identified, but if several pollings over a WAN yield different time offsets, The network jitter on a LAN between different NTP nodes can be some tens of microseconds, and over a WAN connection it may be even milliseconds. If ntpd queries the time from a GPS clock and/or PPS source then the jitter is usually at the microsecond level. In real life, network packet transportation generally suffers from a mean network delay caused by routers and switches,Īnd variations of the network delay at subsequent pollings, if individual packets are more or less delayed. a few milliseconds, even though the time offset computed by the client is reported as “0”.
This means that the real time offset may be e.g. Then this can't be determined automatically by the client, so this results in a systematic time error at the client side, depending on the ratio of the request and reply delay.
on an ADSL network connection with different upload and download speeds, However, if the delay for requests is always shorter than for replies, or vice versa, e.g. The time accuracy of the client is not affected by the absolute magnitude of the polling delays, as long as the delays are exactly the same for the requests and replies. Specifically, queries across the network require sending a request packet to a server, and waiting for a reply packet from the server. ntpd is the NTP daemon (the NTP service on Windows) that runs in the background,Īnd ntpq is the most important command line tool to check the status of the daemon/service which runs in the background.ĭepending on the type of time source, it takes some time until a submitted request arrives at its destination, and similarly it takes some time until a reply is received.
The NTP software package includes a couple of executable programs. It even measures and compensates its own system clock drift, so that a significant time offset can not even arise during continuous operation of the service. Ntpd runs in the background and continuously adjusts its own system time as accurately as possible, in a way that is not even noticeably for applications. Unlike some other programs for time synchronization which simply step the system time in periodic intervals,
Meinberg makesĪ pre-compiled NTP package for Windows available to simplify installation on Windows. The program was originally written for Unix-like systems, but has also been ported to Windows. Synchronize its own system time to those reference time sources, and at the same time work as NTP server to make its own synchronized system time available to other NTP clients on the network.
The NTP reference implementation, ntpd, has been designed to query the time from one or more configured reference time sources,