#!/bin/blog

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:

http://www.ptb.de/de/org/q/q4/q42/ntp/ntp_main.htm

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. 🙂

Advertisements

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!

dsc00245-500

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:

server 127.127.20.0

Behold the NMEA peer:

ntpdc> peers
     remote           local      st poll reach  delay   offset    disp
=======================================================================
*GPS_NMEA(0)     127.0.0.1        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. 🙂

Blog at WordPress.com.