Network Time Protocol
lastmod 2024-05-27created 2014-05-2227 edits
Network Time Protocol (NTP) is a networking protocol for clock synchronization between computer systems over packet-switched, variable-latency data networks.
In operation since before 1985, NTP is one of the oldest Internet protocols still in use. NTP was designed by David L. Mills of the University of Delaware.
Categories
Projects
- docker-ntp
- Chrony NTP Server running in a Docker container (without the priviledged flag)
- https://github.com/cturra/docker-ntp
NTPQ usage
To send a query to ntp:
## 각 피어의 상태의 요약과 함께, 서버의 현재 피어목록을 획득한다.
$ ntpq -c peers
## Obtains and prints a list of association identifiers and peer statuses for in-spec peers of the server being queried.
$ ntpq -c assoc
Korea NTP Server
NTP servers operated in South Korea are as follows.
- kr.pool.ntp.org
- time.bora.net
- time.nuri.net
Facebook NTP Server
Facebook has released a new NTP time service at time.facebook.com. It is more accurate than other public time services and reportedly does not identify users by IP address. Facebook also published a post about the service on its engineering blog. (English)
Large IT companies like Facebook care about time services because they operate distributed systems. To process transactions in distributed databases or guarantee correct logging, many servers need to keep their clocks synchronized with high precision.
Facebook bought specialized test equipment that is Stratum 1 (a device that receives time information directly from satellite atomic clocks) and ran a benchmark comparing ntpd, which has commonly been used as a time server, with chrony ( https://chrony.tuxfamily.org/ ), a relatively new NTP daemon. ntpd temporarily showed an error of -10 ms after first starting and then gradually converged to an error of ±1 ms, while chrony kept most of its error within ±0.2 ms, proving much more accurate than ntpd.
chrony has another advantage: it supports hardware timestamps. NTP, the time synchronization protocol, tries to derive the current time as accurately as possible by stamping a timestamp each time a packet travels between server and client and calculating the time taken for the round trip. However, unless it is a real-time operating system, there is no guarantee that the latency of any given operation stays below a certain level. The same goes for NTP, and this becomes one of the causes of larger errors when synchronizing time over a network.
However, some NICs (network cards) support a hardware timestamp feature. With this feature, the NIC maintains its own clock through separate hardware and handles timestamping, and the processing latency is only a few nanoseconds. In an ideal situation, on a local network where both the NTP server and the client support hardware timestamps, time can reportedly be synchronized with an error of less than 1 microsecond. A real time service is not on a local network, and the client's NIC may not support hardware timestamps, so you can't expect that much, but in any case, a benchmark combining chrony with the hardware timestamp feature reportedly kept most time synchronization errors within ±0.1 ms.
So Facebook reportedly runs its public time service with chrony configured with hardware timestamps enabled. Other public time servers such as Google's or Apple's sometimes serve time with errors exceeding ±2 ms, while Facebook's service is mostly within ±1 ms. For reference, the service runs with endpoints in 5 different regions. See the original article for details.
Examples
See also
Favorite site
- Wikipedia (en) Description of NTP
- SNTP (RFC-1361) protocol
- public ntp time server for everyone 1
- NIST Internet Time Servers
- NTP configuration
- NTP time synchronization
- How do I use pool.ntp.org?
- [Recommended] Setting up NTP
- [Recommended] Setting Up “NTP (Network Time Protocol) Server” in RHEL/CentOS 7
- Linux Home Server HOWTO: Chapter 9 - Network Time Protocol
References
-
A project that provides a big virtual cluster of time servers, reliable and easy to use, for millions of clients ↩