Update ntp

The time kept by the RTC will drift away from actual time by up to 5 minutes per month due to temperature variations. Hence the need for the system clock to be constantly synchronized with external time references. When the system clock is being synchronized by ntpd , the kernel will in turn update the RTC every 11 minutes automatically. NTP servers are classified according to their synchronization distance from the atomic clocks which are the source of the time signals.

The servers are thought of as being arranged in layers, or strata, from 1 at the top down to Hence the word stratum is used when referring to a specific layer. Atomic clocks are referred to as Stratum 0 as this is the source, but no Stratum 0 packet is sent on the Internet, all stratum 0 atomic clocks are attached to a server which is referred to as stratum 1.

These servers send out packets marked as Stratum 1. Servers of the same stratum can exchange packets with each other but are still designated as belonging to just the one stratum, the stratum one below the best reference they are synchronized to. The designation Stratum 16 is used to indicate that the server is not currently synchronized to a reliable time source.

Note that by default NTP clients act as servers for those systems in the stratum below them. These signals can be received by dedicated devices and are usually connected by RS to a system used as an organizational or site-wide time server. This process continues down to Stratum 15 which is the lowest valid stratum. The label Stratum 16 is used to indicated an unsynchronized state. This implementation of NTP enables sub-second accuracy to be achieved. Over the Internet, accuracy to 10s of milliseconds is normal.

This is because clock drift is now accounted and corrected for, which was not done in earlier, simpler, time protocol systems. A resolution of picoseconds is provided by using bit time stamps. The first bits of the time stamp is used for seconds, the last bits are used for fractions of seconds. As bits is used to count the seconds, this means the time will "roll over" in However NTP works on the difference between time stamps so this does not present the same level of problem as other implementations of time protocols have done.

If a hardware clock that is within 68 years of the correct time is available at boot time then NTP will correctly interpret the current date.

The NTP4 specification provides for an "Era Number" and an "Era Offset" which can be used to make software more robust when dealing with time lengths of more than 68 years. Do not confuse this with the Unix Year problem. The NTP protocol provides additional information to improve accuracy.

Four time stamps are used to allow the calculation of round-trip time and server response time. In order for a system in its role as NTP client to synchronize with a reference time server, a packet is sent with an "originate time stamp".

When the packet arrives, the time server adds a "receive time stamp". After processing the request for time and date information and just before returning the packet, it adds a "transmit time stamp".

When the returning packet arrives at the NTP client, a "receive time stamp" is generated. The client can now calculate the total round trip time and by subtracting the processing time derive the actual traveling time.

By assuming the outgoing and return trips take equal time, the single-trip delay in receiving the NTP data is calculated. The full NTP algorithm is much more complex than presented here.

When a packet containing time information is received it is not immediately responded to, but is first subject to validation checks and then processed together with several other time samples to arrive at an estimate of the time.

The system clock is adjusted slowly, at most at a rate of 0. It will take at least seconds to adjust the clock by 1 second using this method. This slow change is referred to as slewing and cannot go backwards.

If the time offset of the clock is more than ms the default setting , ntpd can "step" the clock forwards or backwards. If the time offset at system start is greater than seconds then the user, or an installation script, should make a manual adjustment.

See Chapter 3, Configuring the Date and Time. With the -g option to the ntpd command used by default , any offset at system start will be corrected, but during normal operation only offsets of up to seconds will be corrected. Some software may fail or produce an error if the time is changed backwards.

For systems that are sensitive to step changes in the time, the threshold can be changed to s instead of ms using the -x option unrelated to the -g option. Using the -x option to increase the stepping limit from 0. It disables the kernel clock discipline and may have a negative impact on the clock accuracy. The drift file is used to store the frequency offset between the system clock running at its nominal frequency and the frequency required to remain in synchronization with UTC.

If present, the value contained in the drift file is read at system start and used to correct the clock source. Use of the drift file reduces the time required to achieve a stable and accurate time. The value is calculated, and the drift file replaced, once per hour by ntpd. The drift file is replaced, rather than just updated, and for this reason the drift file must be in a directory for which the ntpd has write permissions.

See Chapter 3, Configuring the Date and Time for information on how to use that tool. The operation of ntpd is explained in more detail in the man page ntpd 8. The resources section lists useful sources of information. See Section NTPv4 NTPv4 added support for the Autokey Security Architecture, which is based on public asymmetric cryptography while retaining support for symmetric key cryptography. Unfortunately, it was found later that the protocol has serious security issues, and thus Red Hat strongly recommends to use symmetric keys instead.

An attacker on the network can attempt to disrupt a service by sending NTP packets with incorrect time information. If only one time source is compromised or spoofed, ntpd will ignore that source. You should conduct a risk assessment and consider the impact of incorrect time on your applications and organization.

If you have internal time sources you should consider steps to protect the network over which the NTP packets are distributed. If you conduct a risk assessment and conclude that the risk is acceptable, and the impact to your applications minimal, then you can choose not to use authentication. The broadcast and multicast modes require authentication by default. If you have decided to trust the network then you can disable authentication by using disable auth directive in the ntp. Alternatively, authentication needs to be configured by using SHA1 or MD5 symmetric keys, or by public asymmetric key cryptography using the Autokey scheme.

To implement symmetric key cryptography, see Section The Type parameter can have the following outcomes: NoSync — the time service is not synchronized.

NTP — the time service is synchronized with the servers specified in the NtpServer parameter. NT5DS — the time service is synchronized within a domain hierarchy. AllSync — the time service successfully uses all possible methods for synchronization. Related Articles. How To Delete User Profiles Remotely with PowerShell Dec 1, How-to Articles When a user logs onto the computer for the first time not via the network to access shared folders or printers , Windows creates a user profile.

Submit a Comment Cancel reply Your email address will not be published. Comment Name Email Website Save my name, email, and website in this browser for the next time I comment.

Patch Management Identify and deploy missing OS and third-party software updates. Software Deployment Distribute software and updates across managed endpoints. IT Asset Inventory Keep a detailed inventory and manage hardware and software assets.

Remote Desktop Support users via seamless remote desktop connection. Unattended Access Provide administrative support and manage remote devices. This is an example of both debugs. Initially, the client clocks were synced. The debug ntp events command shows that an NTP peer stratum change occurred, and the clocks then went out of sync. Do not attempt to manually use the ntp clock-period command. Ensure that you remove this command line when copying configuration files to other devices.

The ntp clock-period command automatically appears in the configuration when you enable NTP. The command is used in order to adjust the software clock.

The 'adjustment value' compensates for the 4 msec tick interval, so that, with the minor adjustment, you have 1 second at the end of the interval.

If the device has calculated that its system clock is losing time perhaps there needs to be a frequency compensation from the base level of the router , it automatically adds this value to the system clock in order to maintain its synchronicity.

Note : This command should not be changed by the user. For example, the system clock for the Cisco routers one of the Cisco Series Routers was found to be slightly out-of-sync and could be resynchronized with this command:. Cisco recommends that you let the router run for a week or so in normal network conditions and then use the wr mem command in order to save the value.

This gives you an accurate figure for next reboot and allows NTP to synchronize more quickly. Use the no ntp clock-period command when you save the configuration for use on another device because this command drops the clock-period back to the default of that particular device. The true value will be recalculated but will reduce the accuracy of the system clock during that recalculation time period. Remember that this value is hardware dependent, so if you copy a configuration and use it on different devices, you can cause problems.

Cisco plans to replace NTP version 3 with version 4 in order to resolve this issue. If you are not aware of these issues, you may decide to manually tinker with this value. In order to migrate from one device to another, you may decide to copy the old configuration and paste it on the new device. Unfortunately, because the ntp clock-period command appears in the running-config and startup-config, NTP clock-period is pasted on the new device.

When this happens, NTP on the new client always goes out of sync with the server with a high peer dispersion value.

Instead, clear the NTP clock-period with the no ntp clock-period command, then save the configuration. The router eventually calculates a clock-period appropriate for itself. So, you are not allowed to configure the clock-period manually, and the clock-period is not allowed in the running-config. Since the parser rejects the command if it was in the start-up config in earlier Cisco IOS versions such as Contents Introduction. The tests are: Test Mask Explanation 1.

The sanity checks have failed, so time from the server is not accepted. The server is unsynced. This is the poll interval from our poll to this peer or from the peer to the local machine. EBF A2F44E2C A sample is the last NTP packet received. NTP avoids synchronization with a machine whose time might be ambiguous in these ways: NTP never synchronizes to a machine that is not synchronized itself.

Cheers to Prashant, who solved that issue. I am running a raspbian debian wheezy on my raspberry pi, which doesn't have the hwclock. I found it handy to write a little script and run it after my internet interface is up, so that I am sure that the moment the network becomes available, the clock gets updated. The ntpd algorithms discard sample offsets exceeding ms, unless the interval during which no [absolute value of] 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. Normally, ntpd exits if the offset exceeds the sanity limit, which is s by default. This can be turned off with the -g option:. If the sanity limit is set to zero, no sanity checking is performed and any offset is acceptable. This option overrides the limit and allows the time to be set to any value without restriction; however, this can happen only once.

After that, ntpd will exit if the limit is exceeded. This option can be used with the -q option. If you are behind a firewall, ntpd will never work, but ntpdate can work with the -u option.

For example: ntpdate -u 0. If you can afford the time to wait whatever time it takes before your system gets in sync, you can use the ntp-wait command:. For Ubuntu and the like use: dpkg-reconfigure tzdata and select the right locale. It keeps its value between restarts. Ubuntu Community Ask! Sign up to join this community. The best answers are voted up and rise to the top. Stack Overflow for Teams — Collaborate and share knowledge with a private group.

Create a free Team What is Teams? Learn more. How to force a clock update using ntp? Ask Question. Asked 8 years, 11 months ago. Active 8 months ago. Viewed 1. How can I force a clock update at any given time? Here's what I tried: Replace the server to us. Improve this question. From ntpdate's man page: "Force the time to be stepped using the settimeofday system call, rather than slewed default using the adjtime system call. This option should be used when called from a startup file at boot time.

Consider that the the '-B' flag it mentions that offsets over ms can take hours to sync using the default 'slew' mechanism — Matt S. Add a comment. Active Oldest Votes. Instead of ntpdate which is deprecated , use ntpd : sudo service ntp stop sudo ntpd -gq sudo service ntp start The -gq tells the ntp daemon to correct the time regardless of the offset g and exit immediately q after setting the time.

Improve this answer. Reading ntpd manpage, I am not sure how this forces an update? The "-q" option tells the NTP daemon to start up, set the time and immediately exit.

The "-g" option allows it to correct for time differences larger then sec. For longer term, you should simply configure the NTP daemon to be running always.

This answer should go to the top, because it is correct: ntpdate is deprecated and installing it is a bad idea, because it conflicts with ntp.