The translation is temporarily closed for contributions due to maintenance, please come back later.
The translation was automatically locked due to following alerts: Could not merge the repository.
Zen

Source string Source string

740/10000 · 740

This translation is currently locked.

English Actions
These signals can be received by dedicated devices and are usually connected by RS-232 to a system used as an organizational or site-wide time server.
Stratum 1
Computer with radio clock, GPS clock, or atomic clock attached
Stratum 2
Reads from stratum 1; Serves to lower strata
Stratum 3
Reads from stratum 2; Serves to lower strata
Stratum _n+1_
Reads from stratum _n_pass:attributes[{blank}]; Serves to lower strata
Stratum 15
Reads from stratum 14; This is the lowest stratum.
This process continues down to Stratum 15 which is the lowest valid stratum. The label Stratum 16 is used to indicated an unsynchronized state.
Understanding NTP
The version of `NTP` used by {MAJOROS} is as described in [citetitle]_link:++http://www.rfc-editor.org/info/rfc1305++[RFC 1305 Network Time Protocol (Version 3) Specification, Implementation and Analysis]_ and [citetitle]_link:++http://www.rfc-editor.org/info/rfc5905++[RFC 5905 Network Time Protocol Version 4: Protocol and Algorithms Specification]_
This implementation of `NTP` enables sub-second accuracy to be achieved. Over the Internet, accuracy to 10s of milliseconds is normal. On a Local Area Network (LAN), 1 ms accuracy is possible under ideal conditions. This is because clock drift is now accounted and corrected for, which was not done in earlier, simpler, time protocol systems. A resolution of 233 picoseconds is provided by using 64-bit time stamps. The first 32-bits of the time stamp is used for seconds, the last 32-bits are used for fractions of seconds.
`NTP` represents the time as a count of the number of seconds since 00:00 (midnight) 1 January, 1900 GMT. As 32-bits is used to count the seconds, this means the time will "roll over" in 2036. 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. Note, please do not confuse this with the Unix Year 2038 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. This is then compared to the system clock to determine the time offset, the difference between the system clock's time and what `ntpd` has determined the time should be. The system clock is adjusted slowly, at most at a rate of 0.5ms per second, to reduce this offset by changing the frequency of the counter being used. It will take at least 2000 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 128ms (the default setting), `ntpd` can "step" the clock forwards or backwards. If the time offset at system start is greater than 1000 seconds then the user, or an installation script, should make a manual adjustment. See xref:../basic-system-configuration/Configuring_the_Date_and_Time.adoc#ch-Configuring_the_Date_and_Time[Configuring the Date and Time]. With the [option]`-g` option to the [command]#ntpd# command (used by default), any offset at system start will be corrected, but during normal operation only offsets of up to 1000 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 600s instead of 128ms using the [option]`-x` option (unrelated to the [option]`-g` option). Using the [option]`-x` option to increase the stepping limit from 0.128s to 600s has a drawback because a different method of controlling the clock has to be used. It disables the kernel clock discipline and may have a negative impact on the clock accuracy. The [option]`-x` option can be added to the `/etc/sysconfig/ntpd` configuration file.
Understanding the Drift File
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.
UTC, Timezones, and DST
As `NTP` is entirely in UTC (Universal Time, Coordinated), Timezones and DST (Daylight Saving Time) are applied locally by the system. The file `/etc/localtime` is a copy of, or symlink to, a zone information file from `/usr/share/zoneinfo`. The RTC may be in localtime or in UTC, as specified by the 3rd line of `/etc/adjtime`, which will be one of LOCAL or UTC to indicate how the RTC clock has been set. Users can easily change this setting using the checkbox `System Clock Uses UTC` in the [application]*Date and Time* graphical configuration tool. See xref:../basic-system-configuration/Configuring_the_Date_and_Time.adoc#ch-Configuring_the_Date_and_Time[Configuring the Date and Time] for information on how to use that tool. Running the RTC in UTC is recommended to avoid various problems when daylight saving time is changed.
The operation of `ntpd` is explained in more detail in the man page `ntpd(8)`. The resources section lists useful sources of information. See xref:Configuring_NTP_Using_ntpd.adoc#s1-ntpd_additional-resources[Additional Resources].
Authentication Options for NTP
`NTPv4` added support for the Autokey Security Architecture, which is based on public asymmetric cryptography while retaining support for symmetric key cryptography. The Autokey Security Architecture is described in [citetitle]_link:++http://www.rfc-editor.org/info/rfc5906++[RFC 5906 Network Time Protocol Version 4: Autokey Specification]_. The man page `ntp_auth(5)` describes the authentication options and commands for `ntpd`.
An attacker on the network can attempt to disrupt a service by sending `NTP` packets with incorrect time information. On systems using the public pool of `NTP` servers, this risk is mitigated by having more than three `NTP` servers in the list of public `NTP` servers in `/etc/ntp.conf`. 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 [command]#disable auth# directive in the `ntp.conf` file. Alternatively, authentication needs to be configured by using SHA1 or MD5 symmetric keys, or by public (asymmetric) key cryptography using the Autokey scheme. The Autokey scheme for asymmetric cryptography is explained in the `ntp_auth(8)` man page and the generation of keys is explained in `ntp-keygen(8`). To implement symmetric key cryptography, see xref:Configuring_NTP_Using_ntpd.adoc#s2_Configuring_Symmetric_Authentication_Using_a_Key[Configuring Symmetric Authentication Using a Key] for an explanation of the [option]`key` option.
Managing the Time on Virtual Machines
Virtual machines cannot access a real hardware clock and a virtual clock is not stable enough as the stability is dependent on the host systems work load. For this reason, para-virtualized clocks should be provided by the virtualization application in use (for more information see _https://docs.fedoraproject.org/en-US/Fedora/18/html/Virtualization_Administration_Guide/sect-Virtualization-Tips_and_tricks-Libvirt_Managed_Timers.html[Libvirt Managed Timers]_ in the _Virtualization Administration Guide_). On {MAJOROS} with [application]*KVM* the default clock source is [option]`kvm-clock`. See the [citetitle]_link:++https://docs.fedoraproject.org/en-US/Fedora/13/html/Virtualization_Guide/chap-Virtualization-KVM_guest_timing_management.html++[KVM guest timing management]_ chapter of the [citetitle]_Virtualization Host Configuration and Guest Installation Guide_.
Understanding Leap Seconds

Loading…

User avatar None

String updated in the repository
`NTP` represents the time as a count of the number of seconds since 00:00 (midnight) 1 January, 1900 GMT. As 32-bits is used to count the seconds, this means the time will "roll over" in 2036. 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. Note, please do not confuse this with the Unix Year 2038 problem.
`NTP` represents the time as a count of the number of seconds since 00:00 (midnight) 1 January, 1900 GMT. As 32-bits is used to count the seconds, this means the time will "roll over" in 2036. 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. Note, please do not confuse this with the Unix Year 2038 problem.
a year ago
Browse all string changes

Things to check

Long untranslated

The string has not been translated for a long time

Reset

Glossary

English English
No related strings found in the glossary.

14683459 String information

Source string description
type: Plain text
Flags
read-only
Source string location
./pages/servers/Configuring_NTP_Using_ntpd.adoc:58
String age
a year ago
Last updated
a year ago
Source string age
a year ago
Translation file
pot/f27/pages/servers/Configuring_NTP_Using_ntpd.pot, string 30