Windows does not need to know that the NTP server is running Linux. Once Chrony is configured to answer clients on the local network, Windows Time Service treats it in the same way as any other NTP source.
A Chrony server can be installed on an existing Linux system that already operates continuously. There is no requirement for a dedicated computer. A Docker host, monitoring server, ADS-B receiver, home automation system or other small Linux machine may already provide a suitable platform.
Why use Chrony?
Chrony is designed to synchronise the system clock and can also provide NTP service to other devices. It works well on physical systems, virtual machines and computers whose network connectivity is not always available.
For a Windows administrator, the main advantages are straightforward:
- One local source for Windows, Linux and network devices.
- Support for several upstream NTP peers.
- Good visibility through the
chronyccommand. - Support for hardware reference clocks, including GPS and PPS.
- A lightweight service that can run on an existing Linux host.
Chrony as a central Internet-backed source
A Chrony server can use the NTP Pool Project or another public service and distribute that time locally. This provides a single point of configuration and means only the Chrony host needs direct access to external NTP servers.
This can be useful in a larger workgroup or where outbound NTP traffic is restricted. However, it should be recognised for what it is: a central local relay for Internet-backed time, not an independent reference.
For a small environment with only a few Windows computers, configuring every system with the same external peers may be simpler.
Chrony with GPS
Adding a USB GPS receiver gives the Chrony server a local reference that does not depend on Internet connectivity. A receiver that provides a pulse-per-second signal can offer greater precision, although a basic GPS receiver is sufficient for many home-lab and general infrastructure uses.
The combination is attractive because it does not require expensive hardware. Where a Linux host already operates continuously, the only additional equipment may be the GPS receiver.
Chrony can still retain public NTP peers alongside GPS. Those peers provide comparison and resilience if satellite reception is lost or the receiver becomes unavailable.
A practical home-lab project
A GPS-backed Chrony server is an enjoyable home-lab project and a useful way to understand NTP, reference clocks and Windows Time Service.
An existing Linux system can run Chrony alongside its current workload. Connect a USB GPS receiver, configure Chrony to use it and publish the service through a stable DNS name such as:
time.example.com
Windows systems and network devices can then use that name without needing to know which server or software provides the service.
If the Chrony host is later replaced, or the local service is temporarily removed, the DNS record can be changed to another internal server or a public NTP source without reconfiguring every client.
Using a stable DNS name
A local Chrony service should normally be presented through an organisational DNS name rather than the Linux server's own hostname.
This is particularly valuable where many different systems use the service. Windows servers, hypervisors, switches, firewalls, NAS devices, UPSs, cameras and other equipment can all retain the same configuration while the underlying implementation changes.
Monitoring Chrony clients
The chronyc clients command shows the systems contacting the Chrony server. Administrators who prefer a graphical interface can use TICC-DASH, which presents Chrony client activity through a web dashboard.
TICC-DASH can show which clients have contacted the server, their activity and when they were last seen. It is useful for confirming that Windows systems and network devices are reaching Chrony.
It does not prove that a Windows computer has selected Chrony as its current source. Verify that separately on Windows:
w32tm /query /source
w32tm /query /status
When is Chrony a good choice?
Chrony is particularly suitable where:
- A Linux host already operates continuously.
- Windows and non-Windows devices need one local source.
- A GPS receiver will provide an independent reference.
- Internet NTP access is restricted to a small number of systems.
- The administrator wants detailed visibility of sources and clients.
It may be unnecessary for a very small environment where every computer can simply use the same public NTP peers.