November 28, 2019

Aggressive NTP configuration on Windows 10

Filed under: Uncategorized — Tags: , , , — martin @ 1:07 pm

Screenshot of time.is in Esperanto

While clicking around on time.is, which has a nice Esperanto translation that you may want to to check out, I kept running into large-ish time offsets of at least several tenths of a second on a Windows 10 machine.

As a Linux guy, my first instinct was to replace the interval-based synchronization option in Windows with an NTP daemon, and indeed I found Meinberg’s ntpd distribution for Windows. While this ntpd would start flawlessly, over the course of every day it ran into some impossible to debug condition where NTP time reached a significant offset from the system clock again and unlike at startup, the daemon wouldn’t adjust the system clock anymore.

So I turned back to Windows’ built-in time synchronization. Indeed, the people at Meinberg also have helpful advice for it and suggest a few defaults to keep the system clock closely tied to an NTP reference clock. So here’s an attempt at configuring a clean NTP setup on Windows 10.

First of all, the timekeeping service needs to be stopped and fortunately Windows 10 provides the ability to start over with a fresh timekeeping configuration (all following actions must be applied using an administrator role):

net stop w32time
w32tm /unregister
w32tm /register

At this point, the defaults as suggested by Meinberg can be added to the registry:

Windows Registry Editor Version 5.00


Finally, a restart of the timekeeping service and configuration of the NTP reference clocks:

net start w32time
sc config w32time start=auto
w32tm /config /syncfromflags:manual /manualpeerlist:"0.pool.ntp.org 1.pool.ntp.org 2.pool.ntp.org 3.pool.ntp.org" /update

NTP synchronization status can be queried using the w32tm command again:

w32tm /query /peers
w32tm /query /status /verbose

In my highly scientific observation of the system, I haven’t seen any clock offsets ever since.

Further reading: “Windows Time Service Tools and Settings” by Microsoft.

May 11, 2012

Darf man die NTP-Server der PTB nutzen?

Filed under: Internet, UNIX & Linux — Tags: , — martin @ 9:34 am

Auf einer Mailingliste wurde mal wieder die Devise herausgegeben, man solle nicht ohne weiteres die NTP-Zeitserver der Physikalisch-Technischen Bundesanstalt PTB benutzen, sondern stattdessen auf pool.ntp.org zugreifen.

Ich habe diese Geschichte, die schon so lange erzählt wird, wie ich NTP kenne, für eine Urban Legend gehalten und deshalb mal bei der PTB direkt angefragt:

mir läuft schon seit vielen Jahren in Linux- und UNIX-Kreisen ein Ratschlag über den Weg, in dem es heißt, die NTP-Server der PTB seien nicht für die allgemeine öffentliche Nutzung gedacht. Stattdessen solle man sich bei anderen Quellen bedienen, wie z.B. mittlerweile bei pool.ntp.org.

Ich habe selbst leider keine Erfahrungswerte mit NTP-Servern mit Hunderttausenden oder Millionen von Clients, daher kann ich mir selbst keinen Reim darauf machen, wieviel Plausibilität ich dieser Geschichte beimessen soll.

Können Sie mir sagen, ob es für die NTP-Server der PTB irgendwelche Nutzungsbedingungen oder Einschränkungen gibt, die zu beachten sind? Gibt es Auslastungsdaten der Server, die Sie öffentlich machen können?

Daraufhin habe ich sehr schnell die folgende Antwort erhalten:

Gern können Sie unseren NTP-Zeitdienst benutzen. Bitte beachten Sie auch die Hinweise unter:


Grundsätzlich sind unsere NTP-Server für die allgemeine Nutzung freigegeben. Die Auslastungsdaten stellen wir nicht öffentlich bereit. Derzeit ist es jedoch so, dass uns pro Sekunde mehrere Tausend Abfragen auf dem NTP-Port erreichen. Diese stellen aber kein Problem dar! Problematischer sind nur die Abfragen auf dem Time- und Daytime-Port, die wir daher begrenzen.

Sprich: Jedermann kann die NTP-Server der PTB ohne weiteres benutzen, um die gesetzliche Zeit der Bundesrepublik Deutschland zu beziehen. Meine Theorie, daß es sich bei den vermuteten Einschränkungen hinsichtlich ihrer Nutzbarkeit um Urban Legends handelt, war also zutreffend. 🙂

November 24, 2008

Testing and amusement. And doodles.

Filed under: Misc — Tags: , — martin @ 2:37 pm

From the NTP documentation:

frac: Discard received NTP packets with probability 0.1; that is, on average drop one packet in ten. This is for testing and amusement.

And a smiley from a blue LED at a client’s datacenter. Someone drew this into the smudge on the inside of the rack door. Have a nice day!


August 29, 2008

Garmin GPSmap 60C / CS / CSx as an NTP reference clock

Filed under: Hardware, UNIX & Linux — Tags: , , — martin @ 8:06 pm

The bad news first: The Garmin’s USB port is not usable at all with ntpd. Although the USB cable can still be used to supply the unit with power, a serial (RS232) cable is required in order to feed location data into ntpd. Cables are available from Garmin (expensive and slightly hard to find) as well as from pfranc.com, which is by far one of the weirdest business websites I have ever seen. 😉

The good news: Once you have the serial cable, using the GPSr for ntpd is a matter of seconds.

The Garmin must be instructed to spew out location data on the serial port, which can be accomplished through the interface configuration menu. The default of “GARMIN” for the serial port has to be changed to “NMEA-In / NMEA-Out”. After making this setting, you can use Minicom to connect to the serial port at 4800/8N1 where you will see a constant stream of data. The $GPRMC lines contain the information that is required for NTP. (Click here for details about the format.)

According to the ntpd documentation, the Garmin will be configured as a “generic NMEA GPS receiver“.

ntpd will require a symlink in /dev so it knows where to find the GPSr. In my case, the Garmin is connected to /dev/ttyS0. Hence, the symlink needs to be created as follows:

# ln -s ttyS0 /dev/gps0

ntpd accesses this device through a pseudo IP address that will be used in ntp.conf:


Behold the NMEA peer:

ntpdc> peers
     remote           local      st poll reach  delay   offset    disp
*GPS_NMEA(0)        0   64  377 0.00000  0.001443 0.03511

Be advised that it will take a few minutes until ntpd has synchronized with the GPSr. If you can’t get your NTP clients to synchronize with your NTP server, leave it alone for a while and try again later. Synchronization with the GPSr is complete as soon as the output from “peers” no longer starts with “=” but with an asterisk (as above). I learned this the hard way during Y2K testing in 1999 when an NTP server just wouldn’t synchronize. I restarted it over and over again. At the end of my tether, I went out for lunch and left the defunct server behind. When I came back, everything had just fallen into place, the clock was synchronized and so were the clients. 🙂

Create a free website or blog at WordPress.com.