UTC(DFM) on your device

DFM’s realization of the coordinated world time UTC(DFM) is now accessible also on your electronic devices via NTP or NTS.

NTP (Network Time Protocol) is an internet protocol that can be used to synchronize your computer’s clock to a time source over the internet.

NTP is designed to produce three-called “products”: clock offset, roundtrip delay, dispersion, all of which are relative to a selected reference clock, in this case the reference clock of DFM’s time server: UTC(DFM).

Clock offset represents an estimate of the server clock time relative to the client clock time. Hence, it states how much to adjust your local clock in order to align it with DFM’s reference clock.
The roundtrip delay is explained in more details in the info box.
Dispersion denotes the maximum error of the clock offset-estimate relative to DFM’s reference, e.g. due to a frequency offset of your local clock, time-stamping errors and potential errors of the server clock.

As DFM’s time server is connected directly to our atomic clock, its clock follows UTC(DFM) to within 20 ns, and when you use time.dfm.dk as time source, you obtain a traceable time on your machine with an accuracy that is essentially only limited by the packet roundtrip delay to our server (see info box).

If you depend on a secure, accurate time, you may also wish to make use of our NTS service. Here, we provide timing information with a digital signature, such that you can always be sure that what you get is genuine DFM time with error bounds we stand in for.

Metrological Traceability

is a property of a measurement result whereby the result can be related to a reference through a documented unbroken chain of calibrations, each contributing to the measurement uncertainty.

BIPM

NTS

is a method for using TLS/SSL to authenticate NTP traffic on the net.

NTS addresses the vulnerabilities of NTP, such as packet manipulation, replay attacks, spoofing, etc. and this proposed internet standard was published by the Internet Engineering Taskforce (IETF) as RFC8915 in September 2020.

NTS can be seen as two protocols linked togeher: a protocol for key establishment, and NTP with some extension fields for time synchronization.

This design of NTS makes it possible to authenticate NTP data while maintaining the NTP functionality.

What's the point of yet another NTP server?

When your computer connects to time.dfm.dk, it will send time request data packets, marked with a time stamp of transmission t0 to us. Our server then adds the time of reception t1 and the time stamp of its response transmission t2 to the packet and sends it back to your computer, where it is time stamped a with its reception time t3.

If the travel time of data packets to DFM and back were exactly the same in both directions, we could know the time offset exactly. But as effects as different internet routes for both directions, differences in up- and downlink speed, packet buffering and line congestion can cause unknown asymmetries, we only know that the clock offset θ lies within

θ = ((t1-t0)+(t2-t3))/2 ± δ/2 ± ε,

where δ is the packet round-trip delay

δ=(t3-t0)-(t2-t1),

and the dispersion ε is the maximum measurement error due to time-stamping and clock frequency drifts during the time interval t0…t3.

Having a traceable NTP server close-by with a small roundtrip delay δ therefore allows for a much more accurate time transfer than using unknown time servers from far abroad.

Within Denmark, most of our users will reach δ/2 ≅ 1 ms.

Last, but not least, the obtainable client clock accuracy also depends on the uncertainty of the server system clock itself, which for time.dfm.dk is bound by ε ≤ 20 ns relative to our atomic clock time UTC(DFM).

Device Configuration

DFM recomments using chrony (V4.0 or higher) as client program, as it supports the new authenticated NTS service.

In most cases just adding the line

server time.dfm.dk nts iburst

to your chrony.conf and restarting the service should be sufficient. Detailed instructions can be found here and here.

Apple Mac users will probably find ChronyControl most convenient. It allows for easy installation of the chrony client software and even offers a graphical user interface for monitoring tracking performance.

Make sure that after installation, your chrony.conf configuration file contains the line
server time.dfm.dk nts iburst
to establish an authenticated connection to DFM’s NTS time server.

Unfortunately, to our knowledge no Windows client supporting the authenticated NTS service exist yet.

In an Actice Directory (AD) corporate setting, Windows machines typically synchronize to their Domain Controller (DC), so if your office machines show the wrong time, a more permanent solution is to get that machine’s time synced up to UTC(DFM) instead – there are a few extra pitfalls if your DC is running on a virtual machine (Hyper-V), but your admin will figure this out…

If this is not desired, or if you don’t use AD, the followig procedure will work:

To configure time.dfm.dk as time server, windows provides the w32tm program (documentation here).

Executing

w32tm /config /syncfromflags:MANUAL /manualpeerlist:"time.dfm.dk,0x8" /update

from a command prompt with administrator rights will configure the NTP server.

w32tm /query /status /verbose

and

w32tm /query /peers

provide information about the current synchronization status (“Phase Offset:” denotes the measured clock error). On Meinberg’s webpage, additional registry values to fine-tune the synchronization behavior are documented.

While Android devices do support synchronizing to NTP servers, there seems to be no user interface to set the server yet. This website describes a one-time procedure on how to set the NTP server setting using the developer-options menu, USB-debugging interface and a PC.

The key step is to connect the device to your PC via USB and use the adb program from https://developer.android.com/tools/releases/platform-tools to add the following setting:

> adb shell settings put global ntp_server time.dfm.dk

and reboot your device

> adb shell reboot

You can then verify that the setting got indeed changed:

> adb shell settings get global ntp_server 
time.dfm.dk
> adb shell logcat --buffer=events *:S ntp_success 
--------- beginning of events 
10-23 11:13:48.532  1573  2005 I ntp_success: [time.dfm.dk/87.116.22.151,21,516]

As most of those computers run a variant of Linux, we recommend chrony as software package (see Linux). As an additional complication, these computers do not have a battery backed real time clock and therefore cannot check the expiry of our digital certificate used for NTS cryptography when their clock is completely wrong at startup. Adding

nocerttimecheck 1

server time.dfm.dk nts iburst

to the chrony.conf configuration file should get you going; further detailed instructions can be found here and here.

IPads and iPhones use Apple’s own NTP servers time.apple.com and time-ios.apple.com, and this cannot be changed by the user. As these servers only use plain NTP and not the authenticated NTS, redirecting the DNS entry in your router/local name server or redirecting the IP traffic in your firewall is your only option of obtaining time traceable to UTC(DFM) on these devices within your private/corporate network.