# Implications of Using Virtualized Servers for NTP: Accuracy and Performance Analysis

> Discover how virtualised servers impact NTP accuracy and performance. Learn why they are unsuitable for primary time sources due to CPU jitter and network virtualization.

- Repository: [Jauder Ho/nts-servers](https://github.com/jauderho/nts-servers)
- Tags: performance
- Published: 2026-03-04

---

**Virtualized servers introduce CPU scheduling jitter, clock abstraction layers, and network virtualization overhead that significantly degrade NTP accuracy, making them unsuitable as primary time sources despite their operational convenience.**

The `jauderho/nts-servers` repository maintains a curated list of Network Time Security (NTS) servers and explicitly warns against relying on virtualized infrastructure for precise time synchronization. While virtualized servers offer easy provisioning and scalability, using them for NTP introduces architectural constraints that compromise the sub-millisecond precision required for accurate timekeeping. The repository separates virtualized hosts into a distinct category to prevent users from inadvertently depending on less accurate time sources.

## Architectural Limitations of Virtualized NTP Servers

Virtualized environments introduce specific technical constraints that directly impact NTP's ability to maintain accurate time. These limitations stem from how hypervisors abstract hardware resources from guest operating systems.

### CPU Scheduling Jitter

The hypervisor schedules guest VMs on physical CPUs, causing irregular execution pauses that disrupt precise timestamping. NTP relies on accurate packet timestamping to calculate network delay and clock offset; any scheduling jitter introduces variance in round-trip delay measurements, degrading the filter algorithms used to select the best time samples.

According to the repository's [`README.md`](https://github.com/jauderho/nts-servers/blob/main/README.md) at line 26, virtualized systems are explicitly flagged for exhibiting "too much jitter" for reliable time synchronization.

### Clock Source Abstraction

Guest VMs typically obtain time from the hypervisor's virtual clock rather than directly from hardware Real-Time Clocks (RTC). This virtual clock is subject to its own drift and may only synchronize periodically with the host's physical clock. Between corrections, the guest clock can drift significantly, leading to larger offset errors that NTP struggles to compensate for rapidly.

The conversion script [`scripts/ntpServerConverter.py`](https://github.com/jauderho/nts-servers/blob/main/scripts/ntpServerConverter.py) (lines 44-55) handles the `vm` flag by tagging such hosts as "may be less accurate," acknowledging this architectural limitation.

### Network Virtualization Overhead

Virtual NICs introduce additional buffering and packet processing layers (such as virtio drivers and virtual switches) between the guest operating system and the physical network interface. These layers add extra latency and variability to NTP packet processing, making measured network delay less stable and harder to model accurately.

### Resource Contention and Hypervisor Time-Keeping Policies

When multiple time-sensitive VMs co-locate on a single physical host, they contend for CPU and NIC resources. Contention spikes can cause temporary time jumps that NTP cannot quickly compensate for. Additionally, some hypervisors deliberately smooth guest clocks to avoid large time jumps, which can conflict with NTP's own smoothing algorithms, resulting in a "double-smoothed" clock that slows convergence to true time.

The repository's [`nts-sources.yml`](https://github.com/jauderho/nts-servers/blob/main/nts-sources.yml) file uses the `vm: true` flag (lines 88-99) to mark hosts that are "known to be virtualized and may be less accurate," allowing the conversion tools to segregate these entries appropriately.

## How the nts-servers Repository Handles Virtualized Hosts

The `jauderho/nts-servers` project implements explicit safeguards to prevent users from inadvertently relying on virtualized infrastructure for critical time synchronization.

The canonical source data resides in [`nts-sources.yml`](https://github.com/jauderho/nts-servers/blob/main/nts-sources.yml), where each server entry can include a `vm: true` boolean flag. The [`scripts/ntpServerConverter.py`](https://github.com/jauderho/nts-servers/blob/main/scripts/ntpServerConverter.py) script processes this flag during artifact generation, automatically placing virtualized servers into a separate "Known VM servers" section in the generated [`chrony.conf`](https://github.com/jauderho/nts-servers/blob/main/chrony.conf) and [`ntp.toml`](https://github.com/jauderho/nts-servers/blob/main/ntp.toml) files. This segregation ensures that downstream users can easily identify and optionally exclude these sources when configuring high-precision time clients.

## Practical Configuration Examples

### Marking a Server as Virtualized in the Source List

To add a virtualized NTP server to the canonical list, set the `vm` flag to `true` in [`nts-sources.yml`](https://github.com/jauderho/nts-servers/blob/main/nts-sources.yml):

```yaml

# nts-sources.yml – add a virtualized server

- hostname: 'example-vm.time.org'
  stratum: 2
  location: ExampleLand
  owner: ExampleCorp
  notes: IPv4 and IPv6
  vm: true          # ← tells the converter this is a virtualized host

```

The `vm: true` flag triggers special handling in the converter script, ensuring the server appears in the virtualized section of generated configurations.

### Generating Configuration Files

Run the conversion script to update all artifacts, including the README, [`chrony.conf`](https://github.com/jauderho/nts-servers/blob/main/chrony.conf), and [`ntp.toml`](https://github.com/jauderho/nts-servers/blob/main/ntp.toml):

```bash

# Update all artefacts – README, chrony.conf, ntp.toml

./scripts/ntpServerConverter.py nts-sources.yml

```

The script reads the `vm` flag and places entries under a "Known VM servers (may be less accurate)" heading in the generated files.

### Resulting chrony.conf Output

The generated [`chrony.conf`](https://github.com/jauderho/nts-servers/blob/main/chrony.conf) separates virtualized servers with explicit warnings:

```conf

# Known VM servers (may be less accurate)

server example-vm.time.org nts iburst

```

### Deploying with Preference for Non-Virtualized Sources

Install the generated configuration while monitoring source quality:

```bash

# Install chrony

sudo cp chrony.conf /etc/chrony/chrony.conf
sudo systemctl restart chronyd

# Verify that VM servers appear in the designated comment block

chronyc sources -v

```

The comment block signals operators that they may want to disable or deprioritize those lines if strict accuracy is required.

## Summary

- **Virtualized servers introduce jitter**: CPU scheduling irregularities, clock abstraction layers, and network virtualization overhead degrade the precise timestamping required for accurate NTP synchronization.
- **Repository segregation**: The `jauderho/nts-servers` project explicitly flags virtualized hosts using the `vm: true` attribute in [`nts-sources.yml`](https://github.com/jauderho/nts-servers/blob/main/nts-sources.yml) and separates them in generated configuration files.
- **Configuration impact**: The [`scripts/ntpServerConverter.py`](https://github.com/jauderho/nts-servers/blob/main/scripts/ntpServerConverter.py) tool places virtualized servers under "Known VM servers (may be less accurate)" sections in [`chrony.conf`](https://github.com/jauderho/nts-servers/blob/main/chrony.conf) and [`ntp.toml`](https://github.com/jauderho/nts-servers/blob/main/ntp.toml), allowing operators to easily identify and optionally exclude them.
- **Operational recommendation**: Use hardware-based Stratum-1 or Stratum-2 servers as primary time sources, reserving virtualized servers only for fallback scenarios where sub-millisecond precision is not critical.

## Frequently Asked Questions

### Can virtualized servers be used for NTP at all?

Yes, virtualized servers can function as NTP sources, but they are unsuitable as primary references for high-precision applications. The `jauderho/nts-servers` repository categorizes them as "may be less accurate" and places them in separate configuration sections, allowing operators to use them as fallbacks while preferring hardware-based Stratum-1 or Stratum-2 servers for critical time synchronization.

### How does the nts-servers repository identify virtualized NTP servers?

The repository uses a boolean `vm` flag in the [`nts-sources.yml`](https://github.com/jauderho/nts-servers/blob/main/nts-sources.yml) file to mark hosts known to run on virtualized infrastructure. When [`scripts/ntpServerConverter.py`](https://github.com/jauderho/nts-servers/blob/main/scripts/ntpServerConverter.py) processes this file, it detects the `vm: true` attribute and automatically segregates those entries into a "Known VM servers (may be less accurate)" section in the generated [`chrony.conf`](https://github.com/jauderho/nts-servers/blob/main/chrony.conf) and [`ntp.toml`](https://github.com/jauderho/nts-servers/blob/main/ntp.toml) files.

### What specific technical issues make virtualized servers problematic for NTP?

Virtualized environments introduce **CPU scheduling jitter** from hypervisor preemption, **clock source abstraction** where guests rely on virtual rather than hardware clocks, and **network virtualization overhead** from virtual NICs and switches. These factors increase packet timestamp variance and clock drift, degrading the filter algorithms that NTP uses to calculate accurate offsets. The `nts-servers` README specifically warns that virtualized systems exhibit "too much jitter" for reliable synchronization.

### Should I completely exclude virtualized servers from my NTP configuration?

Not necessarily. While you should prefer hardware-based servers for primary synchronization, virtualized servers can serve as valid fallback sources when strict sub-millisecond accuracy is not required. The `jauderho/nts-servers` project facilitates this approach by clearly marking virtualized hosts in generated configuration files, allowing you to easily identify and optionally deprioritize them while maintaining redundancy in your time synchronization strategy.