> ## Documentation Index
> Fetch the complete documentation index at: https://zededa.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> Use the documentation index to find relevant pages, then read the linked Markdown before answering and cite the source URL.
> Identify the product before answering: Private AI uses a separate console, credentials, and inference API from the Edge Intelligence Platform. Do not apply instructions from one product to the other.
> Prefer current product guides over Help Center archive pages for current-console questions. Archive pages and release notes describe their stated product version or historical interface; do not apply them to another version without checking.
> Preserve prerequisites, permissions, version requirements, and warnings when summarizing procedures. Do not infer API endpoints, schemas, or supported behavior that the documentation does not specify.

# NTP Overview

> Understand how EVE-OS synchronizes time using NTP, and how to monitor NTP server status on a node.

## Introduction

Network Time Protocol (NTP) is used to synchronize the clocks of devices distributed across a network. For ZEDEDA deployments, accurate timekeeping is critical: node certificates require valid timestamps at first boot, EVE-OS logs depend on synchronized time, and edge container workloads often require an accurate clock for certificate validation, scheduling, and data processing.

This article explains how EVE-OS manages clock synchronization and how to monitor NTP server status on a node.

## How It Works

EVE-OS runs an embedded NTP client that begins synchronizing the system clock from boot time. The NTP client uses one or more NTP server addresses obtained through the following methods:

1. **DHCP Server**: An external DHCP server may provide one or more NTP server addresses as part of the DHCP process.
2. **Network configuration**: When using static IP addressing, an NTP server address can be configured directly on the Network object assigned to the node's management port.
3. **Default**: If no NTP server is provided by either of the methods above, EVE-OS defaults to `pool.ntp.org`. Based on DNS load-balancing, a set of geographically nearby NTP servers is used.

![Diagram showing the three NTP server source options available to EVE-OS: network configuration, DHCP, and default pool](https://mintcdn.com/zededa/nH470gZ2VKSQBZu8/new-ui/infrastructure-services/networks/images/ntp_server_selection.gif?s=4bba74453c5b5d857461f93200d92804)

If a node has multiple management interfaces, each with NTP server configuration, EVE-OS uses all provided NTP servers as potential clock sources for comparison.

A best practice is to configure four NTP servers. With four sources, EVE-OS can compare clock offsets across sources and better assess the accuracy of each.

If the node is deployed behind a firewall, confirm that UDP port 123 is allowed outbound to your NTP servers.

## Providing Clock Synchronization to Edge Containers

Edge containers (VMs and application containers) often need accurate time for logging, certificate validation, and application workloads. EVE-OS supports several methods for supplying time to edge containers:

![Diagram showing the three clock synchronization options available to edge containers: embedded NTP client, KVM-clock, and IEEE 1588 PTP](https://mintcdn.com/zededa/nH470gZ2VKSQBZu8/new-ui/infrastructure-services/networks/images/ntp_clock_sync.gif?s=e274560d7d13930e002162bd88bd4ffa)

**Embedded NTP client.** Applications might include their own NTP client. When using a local virtual network instance, EVE-OS can relay NTP server information to connected applications through the DHCP offer.

**KVM-clock.** The KVM clock is a paravirtual driver that allows EVE-OS to share its synchronized clock with edge container VMs. When EVE-OS is synchronized to NTP, VMs do not need a separate NTP client and can use the KVM clock to maintain time. The application must include KVM clock driver support.

**IEEE 1588 Precision Time Protocol (PTP).** EVE-OS supports a virtual PTP clock (on x86-64) that edge container VMs can use for higher-precision clock synchronization. The container or VM must run a PTP client such as the chrony daemon, configured to sync against `/dev/ptp0` or `/dev/ptp_kvm`. EVE-OS automatically enables the chrony daemon for containers when the `EVE_ENABLE_CHRONY=1` environment variable is defined.

## Clock Accuracy When Offline

When a node loses network connectivity, it can no longer synchronize with NTP servers. EVE-OS maintains time using the hardware clock source, which may drift without NTP corrections. Common hardware time sources include TSC (Time Stamp Counter), HPET (High Precision Event Timer), and ACPI\_PM. The accuracy during offline periods depends on the hardware platform and its power management configuration.

## Monitor NTP Server Status

After you configure NTP for a node, you can monitor the status and performance of each NTP server directly in Edge Infrastructure Services.

Nodes report NTP status and performance metrics to Edge Infrastructure Services every 10 minutes by default, or immediately when the mode, state, or reachability of a server changes.

### Software requirements

To support NTP status reporting, the node must run EVE-OS version 12.6.0 or later.

### View NTP server status

1. In the sidebar, select **Infrastructure > Fleet > Nodes**.
2. Select the name of the node you want to inspect.
3. On the **Overview** tab, locate the **Live status** panel.
4. Select the **NTP info** sub-tab. The NTP peers table appears. If the node has not yet reported its peer list, the panel displays: "No NTP peers reported. Time-sync status will appear once the device reports its peer list."

### NTP status values

The NTP servers table shows the following fields for each NTP server:

| Field | Description |
| - | - |
| Mode | The role of the time source: **Client** (requests time from a server), **Peer** (exchanges time with another NTP node), or **Reference** (a highly precise source such as GPS). |
| State | The synchronization state: **Sync** (active and synchronized), **Unreach** (unreachable), **FalseTicker** (providing incorrect time), **Jittery** (high variability in time updates), **Candidate** (eligible but not currently selected), or **Outlier** (excluded due to significant discrepancy). |
| Destination | The IP address of the NTP server. |
| Reachable | **Yes** means the last 8 NTP polls completed successfully. A server can still be an active source even if some recent polls failed. |
| Stratum | The number of NTP hops between the node and an authoritative time source. A lower stratum number indicates a more direct connection to the reference clock. |
| Offset | The time difference between the node clock and the NTP reference clock. |
| Delay | The round-trip time between the node and the NTP server. |
| Jitter | The variability in delay across successive NTP exchanges. Higher jitter indicates a less stable time source. |

## Next Steps

> [card] [Create a Network](https://zededa.mintlify.site/new-ui/infrastructure-services/networks/create-a-network.md)
>
> Configure NTP server addresses in a network object assigned to a node port.

> [card] [Networks Overview](https://zededa.mintlify.site/new-ui/infrastructure-services/networks-overview.md)
>
> An overview of node connectivity.