FAQ - Frequently Asked Questions About NTP

NTP (Network Time Protocol) is a network protocol that synchronizes the clock of your devices (computers, servers, phones) with reference time sources, such as atomic clocks.

It ensures that all your systems display the same time with millisecond-level accuracy on a local network, and within a few milliseconds over the Internet.

Learn more: Understanding NTP in detail →

The Stratum indicates the hierarchical level of an NTP server in the time distribution chain:

• Stratum 0: Reference time sources (atomic clocks, GPS, radio signals)
• Stratum 1: Servers directly connected to Stratum 0 sources
• Stratum 2: Servers synchronized with Stratum 1
• Stratum 3+: Client devices (PCs, phones, enterprise servers)

The lower the number, the closer the source is to the atomic reference.

👉 For the full hierarchy (Stratum 0 to 16), typical accuracy at each level and a Stratum 1 vs Stratum 2 comparison, read our dedicated guide: NTP Stratum Levels Explained.

NTP transmits time without cryptographic protection. Anyone on the network could theoretically intercept and modify time packets.

NTS (Network Time Security, defined in RFC 8915) adds an authentication layer based on TLS 1.3: your client can verify that the time comes from the expected server and that it has not been tampered with in transit.

Learn more about NTS →

The NTP Pool (ntppool.org) is a collaborative project that brings together over 4,000 NTP servers worldwide. When you configure pool.ntp.org, your device is automatically directed to geographically nearby servers.

RDEM Systems is an active member of the pool with over 10 servers contributing to the French NTP pool (fr.pool.ntp.org).

Why contribute to the NTP pool? →

Yes, our public NTP servers (ntp1 to ntp11.rdem-systems.com) are freely accessible. They are part of the global NTP pool and open to everyone.

For professional needs requiring an SLA, dedicated support or a custom architecture, we offer managed services.

We operate over 10 public NTP servers (ntp1 to ntp11), hosted in datacenters in France and Europe.

• 1 Stratum 1 server: equipped with a GNSS receiver (GPS/Galileo) with PPS signal
• 10+ Stratum 2 servers: synchronized with our Stratum 1 and other trusted sources

All our servers support NTS and are available over IPv4 and IPv6.

Our servers respond on 8 different TLDs for maximum DNS redundancy:

rdem-systems.{be, biz, com, eu, fr, info, net, org}

Tip: Mix TLDs in your configuration to avoid depending on a single DNS registry. For example: ntp1.rdem-systems.fr, ntp2.rdem-systems.eu, ntp3.rdem-systems.net.

Our reliability score is publicly available on the official NTP pool website. We maintain a high score thanks to our redundant infrastructure and 24/7 monitoring.

View our real-time score on ntppool.org →

On Linux, three main NTP clients are available:

• Chrony (recommended): server ntp1.rdem-systems.fr iburst in /etc/chrony/chrony.conf
• NTPd: server ntp1.rdem-systems.fr iburst in /etc/ntp.conf
• systemd-timesyncd: NTP=ntp1.rdem-systems.fr in /etc/systemd/timesyncd.conf

Visit our homepage for an interactive command generator based on your OS and client.

Via browser:

Use our online verification tool to compare your machine's time with our Stratum 1 reference.

Via command line:

• Chrony: chronyc tracking and chronyc sources -v
• NTPd: ntpq -p
• systemd: timedatectl timesync-status
• Windows: w32tm /query /status

You can use the tools check-ntp.net and online-ntp-validator.com to verify your configuration.

NTS is natively supported by Chrony (version 4.0+). Simply add the nts keyword to your configuration:

server ntp1.rdem-systems.fr iburst nts

Complete NTS configuration guide →

Configuring at least 4 NTP servers is a best practice for several reasons:

• Redundancy: if one server goes down, the others take over
• Anomaly detection: the NTP algorithm compares responses and eliminates outliers
• Accuracy: the average of multiple sources is more reliable than a single source
• DNS resilience: mixing TLDs (.fr, .eu, .com) protects against DNS outages

If your clock is off by more than a few seconds:

• Check connectivity: make sure UDP port 123 is not blocked by a firewall
• Force a synchronization: sudo chronyc makestep (Chrony) or sudo ntpdate -b ntp1.rdem-systems.fr
• Check the timezone: timedatectl on Linux
• Check the sources: chronyc sources to see if the servers are responding

For an offset greater than 1000 seconds, Chrony will refuse to correct automatically. Use makestep to force the correction.

NTP uses UDP port 123. If your firewall or network blocks this port:

• Ask your network administrator to open UDP port 123 for outbound traffic
• Use NTS which first establishes a TLS connection on TCP port 4460, before switching to UDP 123
• As a last resort, some clients support HTTP-based synchronization (less accurate)

TOTP (Time-based One-Time Password) codes used for two-factor authentication are based on time. If your device's clock is off by more than 30 seconds compared to the server, the codes will be rejected.

Solution:

• Make sure automatic time synchronization is enabled on your device
• On Android: Settings > System > Date & time > Automatic date & time
• On iPhone: Settings > General > Date & Time > Set Automatically
• On PC: check your NTP configuration

Understanding the link between TOTP and NTP →

KVM virtual machines on Proxmox VE can experience greater clock drift than physical machines. Even though the paravirtualized clock (kvm-clock) improves the situation, a dedicated NTP client (Chrony) remains essential in production.

Recommended configuration:

• Install Chrony in each VM with at least 4 reliable NTP sources
• Enable makestep 1 3 to automatically correct large offsets at startup
• Verify that kvm-clock is the active source: cat /sys/devices/system/clocksource/clocksource0/current_clocksource
• For critical workloads, consider NTS to cryptographically authenticate your time sources

Complete guide: Hosting a public NTP server on a Proxmox VM →

Yes, it is entirely possible and is in fact an increasingly common approach. Modern hypervisors like Proxmox VE (KVM) offer synchronization performance sufficient to serve time to clients, provided the underlying platform is properly configured.

• Use kvm-clock as the clock source in the VM
• The Proxmox host itself must be accurately synchronized (Stratum 1 or 2)
• Prefer Chrony over ntpd for its better virtualization handling
• Virtual network latency is negligible compared to WAN latency

Read our complete experience report →

Incorrect time can have serious security consequences:

• TLS/SSL certificates: manipulated time can cause expired or not-yet-valid certificates to be accepted
• Kerberos authentication: tolerates a maximum offset of 5 minutes by default
• Logs and forensics: inconsistent timestamps make event correlation impossible during a security incident
• Replay attacks: an attacker could replay packets if time is unreliable

Several regulations and standards require reliable time synchronization:

• PCI-DSS (requirement 10.4): synchronization of all system clocks
• MiFID II: 100-microsecond accuracy for high-frequency trading
• GDPR: traceability of personal data access with reliable timestamps
• ISO 27001: control A.12.4.4 on clock synchronization
• NIS2: logging and traceability requirements for security events