Diskussion:Network Time Protocol

Alternativen

"chrony is a versatile implementation of the Network Time Protocol (NTP). It can synchronize the system clock with NTP servers, reference clocks (e.g. GPS receiver), and manual input using wristwatch and keyboard. It can also operate as an NTPv4 (RFC 5905) server and peer to provide a time service to other computers in the network....." http://chrony.tuxfamily.org/

Alternativen zu NTP, UDP Port 123 sind:

• NTPsec, UDP Port 123 https://docs.ntpsec.org/latest/mode6.html

Finding A Time Server

hallo,

eine Liste (sogar mit Suchmaschine) für öffentliche ntp Server gibt es hier:

http://ntp.isc.org/bin/view/Servers/WebHome#Finding_A_Time_Server

Ich weiß nicht, ob es gut ist, im Artikel so tief zu verlinken?
(nicht signierter Beitrag von 217.235.11.65 (Diskussion) 22:46, 26. Mär. 2005 (CET)) --JoBa2282 ^{Red mit mir} 07:41, 17. Sep. 2009 (CEST)

Weblinks

Der Artikel entwickelt sich langsam aber sicher zu einer Linkliste für NTP-Clients. Wikipedia ist kein Webkatalog - die Weblinks sollten mal radikal reduziert werden. Es wäre schön, wenn da max. 5-6 Links als Ergebnis übrigbleiben würden..... Falls das hier keine lesen solle schaue ich die nächsten Tage mal, ob ich dazu komme. --Hansele ^(Diskussion) 12:58, 3. Jun 2005 (CEST)

ntp server

hi, ich würde auch ein paar ntp server direkt mit in der artikel reinschreiben Dktz 17:40, 2. Aug 2006 (CEST)

Nein, neuerdings sollte man 0.pool.ntp.org, 1.pool.ntp.org, 2.pool.ntp.org verwenden. Die Auflösung übernimmt dann das Domain Name System. --Hubi 07:10, 4. Aug 2006 (CEST)

Das "Nein" verstehe ich nicht, es hat mit der Frage nicht direkt zu tun. Man kann doch die drei Alternativen direkt im Artikel erwähnen und jeder würde sie schnell finden. --129.82.6.249 00:45, 17. Sep. 2009 (CEST)

Hallo 129.82.6.249!
Schön, dass du dich an der Wikipedia beteiligen möchtest. Das "Nein" beruht auf zwei Gründen:

1. Es entspricht nicht den Richtlinien der Wikipedia.
   Schau dir hierzu den Artikel "Was Wikipedia nicht ist" an. Insbesondere Punkt 7.3. Links zu artikelspezifischen Fachseiten, oder weiterführende Seiten sind in einem gewissen Maß erwünscht. Das Auflisten von NTP-Servern jedoch nicht.
2. Die wichtigsten Server haben sogar einen eigenen Artikel: NTP-Pool. Dieser wird im Artikel verlinkt. Damit sollte dem Ganzen genüge getan sein.

Ich hoffe die Antwort ist verständlicher!?
"Viel Spaß noch in der Wikipedia!", wünscht dir -- JoBa2282 ^{Red mit mir} 07:35, 17. Sep. 2009 (CEST)

Keine Zeitzone

Der Satz mit dem NTP-Zeitstempel lautete bisher "32 Bits kodieren die Sekunden seit dem 1. Januar 1900 00:00:00 GMT." Die Angabe der Zeitzone GMT ist hier aber falsch. Die 32 Sekundenbits treffen nur eine Aussage über die Anzahl der Sekunden in der implizierten Zeitskala; dagegen wird keine Aussage darüber getroffen, welche Zeitskala denn nun impliziert wird. Insbesondere würde die Verwendung von GMT/UTC nämlich bedeuten, dass man die seit dem Jahr 1900 aufgetretenen Schaltsekunden auch korrekt einbauen müsste, was im Rahmen von NTP definitiv nicht der Fall ist. Mit anderen Worten: Die Anzahl Sekunden seit dem genannten Datum ist eine andere, wenn ich sie auf die GMT-Zeit beziehe (also inklusive Schaltsekunden), als wenn ich den aktuellen NTP-Zeitstempel von eben gerade nehmen würde (also exklusive Schaltsekunden). Langer Rede kurzer Sinn: NTP gibt nur die Sekundenzahl zu jenem Datum. Die Zuordnung zur tatsächlichen Zeitzone muss anderweitig geschehen.
(nicht signierter Beitrag von Cstim (Diskussion | Beiträge) 09:47, 27. Aug. 2007 (CEST)) --JoBa2282 ^{Red mit mir} 07:43, 17. Sep. 2009 (CEST)

Nulldurchgang alle 136 Jahre

Die im Artikel beschriebene Notwendigkeit, das Umspringen der Zeitskala technisch in den Griff zu bekommen, mutet grotesk an. Es handelt sich um eine Marginalie, die keiner Erwaehnung bedarf. Das ist so als muesste eine Software im Jahr 2008 entscheiden, ob sie eben heute oder im Jahr 2144 oder 1872 liefe.(nicht signierter Beitrag von 92.228.24.242 (Diskussion) 19:48, 15. Jun. 2008 (CEST))

Außerdem kann man sich streiten ob 136 ein paar Jahrzehnte sind. Das müsste irgendwie anders formuliert werden oder gleich ganz weggelassen werden. Vor allem beziehen sie diese Information bestimmt nicht aus anderen Quellen sondern wahrscheinlich aus Annahmen der Programmierer. "Obwohl diese Skala also alle 2³² Sekunden umspringt, sind NTP-Implementierungen in der Lage, die tatsächliche Zeit festzustellen, indem sie eine ungefähre Zeit aus anderen Quellen heranziehen. Da dies nur eine Genauigkeit von ein paar Jahrzehnten erfordert, sollte dies im Alltag kein Problem sein."--plaicy 19:44, 3. Sep. 2008 (CEST)

Ich denke, es ist besser so zu formulieren: "Obwohl diese Skala also alle 2³² Sekunden umfasst, sind NTP-Implementierungen in der Lage, die tatsächliche Zeit festzustellen, indem sie eine ungefähre Zeit aus anderen Quellen heranziehen. (Da dies nur eine Genauigkeit von ein paar Jahrzehnten erfordert, sollte dies im Alltag kein Problem sein. => Sinn nicht ganz nachvollziehbar,) Die Ungenauigkeit durch die Laufzeit über das Internet ..." -- Lucia Clemens 23:44, 4. Dez. 2010 (CET)

Inzwischen steht überhaupt nichts mehr zu dieser Thematik im Artikel. Dabei ist doch das, was einem beim Lesen dieses Abschnittes als erstes durch den Kopf geht, dass es 2036 ein Problem geben muss. Die englische WP konnte dieses Problem halbelegant lösen, indem sie auf https://en.wikipedia.org/wiki/Year_2038_problem#NTP_timestamps verlinkt hat. Ich fände irgendeine Erklärung an dieser Stelle besser als keine, da die Antwort ("Ist kein Problem, weil...") nicht unbedingt das ist, was man naiverweise erwarten würde. 85.212.92.94 19:16, 14. Aug. 2015 (CEST)

Es ist bei Computer-Mainboards üblich, dass die BIOS-Uhr im Falle eines Stromausfalls (= Batterie leer) nicht auf irgendeinen Wert vor Beginn des Computerzeitalters resettet wird, sondern auf ein Datum nicht allzu weit in der Vergangenheit. Der Hersteller weiß ja, dass er den Mainboard-Typ XY erst ab dem Jahr 2014 oder so produziert hat. Also stellt er die Uhr so ein, dass sie immer auf den 1.1.2014 resettet. Damit ist dann selbst für den kaputtesten Computer sichergestellt, dass man für NTP-Zwecke eine Zeitangabe vorfindet, die höchstens wenige Jahrzehnte von den tatsächlichen Verhältnissen abweicht. --Echoray (Diskussion) 09:38, 15. Aug. 2015 (CEST)

Soweit schon klar, mein Einwand war ja nur, dass dies irgendwie im Artikel erklärt werden sollte. Es würde m.E. sogar reichen zu sagen, dass das Protokoll eben gewisse Grenzen hat und vom Client verlangt wird, dass dieser über andere Mittel verfügen muss, das Datum zumindest bis auf einige Jahrzehnte genau zu bestimmen. (Nebenbei bemerkt, ich hatte gar keinen PC im Kopf sondern eher so etwas wie ein Embedded System. Diese Dinger können durchaus eine Lebenserwartung von mehreren Jahrzehnten haben. Und manchmal besitzen sie gar keine richtige Uhr, sondern nur einen Zähler, der mit der Zeit ungenau wird oder phasenweise sogar absichtlich abgeschaltet wird um Strom zu sparen.) 85.212.73.32 19:37, 20. Aug. 2015 (CEST)

Lateinisches

hi,

Plural von Stratum = Strati oder Strata ? --87.193.229.58 13:48, 22. Jul. 2008 (CEST)

Ich würde sagen: Strata, denn Stratum ist Neutrum und der Plural Neutrum Nominativ endet mit -A. Joli Tambour 15:02, 22. Jul. 2008 (CEST)

Authentifizierungssysteme

Aus dem Artikel:

Durch die Verwendung moderner Authentifizierungssysteme in Windows 2000 und neueren Versionen (wie Kerberos) wird eine genaue Zeitsynchronisation auch in Microsoft Windows notwendig.

Es ist nicht klar, warum man dafür die genaue Zeit braucht. Im Kerberos-Artikel habe ich dazu auch nichts gefunden. Außerdem wird nicht genannt, wie genau es sein müsste, weshalb man nicht abschätzen kann, ob ein manuelles Stellen der Uhr nicht reichen würde. Ich habe die fragliche Passage daher erstmal entfernt. – 91.4.26.138 20:58, 2. Sep. 2008 (CEST)

Die Aussage ist korrekt. Leider habe ich gerade keine passende Literatur zur Hand, die ich zitieren kann. Aber Kerberos 5 hat gerade durch die Verwendung der Zeitstempeln in den Schlüsseln erheblich an Sicherheit gewonnen. Die Zeitstempel im Schlüssel bei der TGS Kommunikation garantieren, dass keine alten Zeitstempel verwendet werden. Kann man die Zeit manipulieren ergibt sich hier ein Angriffspunkt. Wollen sich zwei Personen untereinander authentifizieren ist ohne Zeitstempel eine dritte Nachricht notwendig.--Merlissimo 00:46, 3. Sep. 2008 (CEST)

Ich meinte nicht, dass das falsch sei; ich sagte nur, dass es nicht klar war. Ich habe mal deine Antwort aufgegriffen und eingearbeitet. Ich weiß aber immer noch nicht, wie problematisch eine dritte Nachricht oder manuelles Uhrstellen wäre. – 91.4.26.138 01:41, 3. Sep. 2008 (CEST)

Einfaches Beispiel für Windows 2000 Server: der Primary Domain Server und sein Stellvertreter Second Domain Server müssen sich miteinander darüber abstimmen können, wer sich im Netz gerade an- oder abgemeldet hat. Wie soll das gehen, wenn einer oder beide mit falscher Zeit laufen? An solchen Fragen hängt in der Praxis auch der eigene Job!

Zur Theorie der Synchronisationsprobleme: Wenn die eigene Systemzeit geringfügig vorgeht, dann stellt man um 10:05 Uhr eine Frage und bekommt um 10:02 Uhr eine Antwort. Es liegt auf der Hand, dass die Toleranz eines vernetzten Systems bei grösser werdender Zeitdifferenz nachlässt (vgl. diese Arbeit).

Insofern sollte man den Hinweis auch im Artikel wieder aufnehmen. -- Courrier 09:51, 24. Nov. 2008 (CET) Nachtrag 77.181.233.237 11:40, 24. Nov. 2008 (CET)

Stratum

Meines Wissens erhalten Zeitquellen ausserhalb von NTP (DCF77-Uhren, GPS-Mäuse) das Stratum 0, die von ihnen gesteuerten NTP-Server das Stratum 1, die von diesen gesteuerten NTP-Server das Stratum 2 usw. So ist es jedenfalls bei allen NTP-Servern, die ich bisher gesehen oder eingerichtet habe. Über die Güte der Zeitquelle sagt das Stratum im Einzelfall nicht viel aus. So sind beispielsweise GPS-Mäuse, deren NMEA-Signal herangezogen wird, nicht überwältigend genaue Zeitquellen, bekommen jedoch trotzdem das Stratum 0. Im RFC 1305 heißt es dazu: ...stratum, with the topmost level (primary servers) assigned as one and each level downwards (secondary servers) in the hierarchy assigned as one greater than the preceding level. Weiterhin steht dort zu lesen, dass man mit einem gewissen Aufwand an der Netzschnittstelle eines Stratum-1-Servers eine Genauigkeit von 1 ms erreichen kann. Dies ist aber keine Forderung. --Wualex 21:44, 24. Sep. 2008 (CEST)

Also wie funktioniert das jetzt?

Was mir in diesem Artikel fehlt, ist eine laientaugliche Erklärung zu einer für mich zentralen, spannenden Frage: Wie ist es möglich, über das Internet die Zeit so genau zu synchronisieren? Die Datenübermittlung braucht ja immer einen Moment, und man weiss nicht, wie lange. Wie kann also der eine Computer herausfinden, wann der andere ihm ein bestimmtes Signal gesendet hat? Danke für die Erklärung! --193.5.216.100 08:06, 21. Jul. 2009 (CEST)

Ja, der Artikel ist noch ausbaufähig. Ich habe mal gerade in RFC 1059 reingeguckt, die älteste Protokolldokumentation, die zu didaktischen Zwecken sicherlich gut geeignet ist. Die Sache funktioniert in etwa wie folgt: Der Client schickt ein Paket an den Server(das die Uhrzeit enthält, die gerade beim Client herrscht) und merkt sich im Speicher, wann er es abgeschickt hat. Der Server empfängt das Paket und schreibt seine Idee von der Uhrzeit hinein, bevor er es wieder zurückschickt. Der Client empfängt diese Nachricht und kann die Differenz zwischen Sende- und Empfangszeitpunkt ausrechnen (die Roundtrip-Zeit). Das reicht aber noch nicht, denn die Uhr auf dem Client wird vermutlich zu schnell oder zu langsam gehen, so dass die Roundtrip-Zeit falsch berechnet wird. Aus diesem Grund wiederholt man das Paket-senden-und-empfangen ein paar Mal und guckt sich mit einer bestimmten Formel die Differenzen zwischen der Client-Uhrzeit und der Server-Zeit an. Diese geben logischerweise einen Hinweis auf die korrekte Roundtrip-Zeit. --Echoray 09:07, 21. Jul. 2009 (CEST)

Kann das bitte jemand im Artikel ergänzen? Eigentlich stellt es ja dessen Hauptinhalt dar. --Azaël 17:41, 12. Okt. 2009 (CEST)

Wäre allerdings wichtig. Weil oft fälschlicherweise geglaubt wird die Latenz geht als Fehler ein. Tatsächlich geht nur die Schwankung und die Asymmetrie der Latenz als Fehler ein. Alex42 12:28, 22. Mär. 2010 (CET)

Ist schon seltsam, dass man die Diskussionsseite lesen muss um zu finden, was man eigentlich im Artikel gesucht hat... und das seit drei Jahren!!92.231.87.176 22:21, 21. Jan. 2013 (CET)

Mittlerweile über zehn Jahre, obwohl der Artikel permanent bearbeitet wird. Insbesondere wird mit keinem Wort auf den systematischen Fehler der Asymmetrie eingangen und fälschlicherweise der Eindruck erweckt, als ließe sich dieser durch statistische Verfahren eliminieren. --2003:E5:BF28:1500:C87D:275A:B4C1:B384 12:40, 13. Feb. 2022 (CET)

Genauigkeit

"NTPv4 kann die lokale Zeit eines Systems über das öffentliche Internet mit einer Genauigkeit von 10 Millisekunden halten, in lokalen Netzwerken sind unter idealen Bedingungen sogar Genauigkeiten von 200 Mikrosekunden und besser möglich." Gibt es dafür eine Quelle / Berechnung? --88.134.156.100 20:01, 5. Jan. 2009 (CET)

Suche auch eine Quelle dazu. Kann mir vorstellen, dass man besser 1ms erreicht. Alex42 12:28, 22. Mär. 2010 (CET)

Seit alles digital ist, hat sich die Latenz von 1 mS auf 1S vertausendfacht. (nicht signierter Beitrag von 2003:E5:BF41:A00:B968:698A:9C7E:6F42 (Diskussion) 10:20, 8. Jan. 2024 (CET))

offizelle zeitserver

da ja viele Staaten eigene Zeit-Referenenzen haben wäre es vielleicht passen die jeweiligen Staaten anzuführen, als Anfang mal die offizellen ntp für AT

DNS-Name	IP
bevtime1.metrologie.at	217.19.37.26
bevtime2.metrologie.at	217.19.37.20
time.metrologie.at	217.19.37.27

Ich halte das für keine gute Idee. Je mehr Stratum-1-Server irgendwo veröffentlicht werden, desto mehr unbedarfte Anwender versuchen, sich die Zeit direkt dort zu holen. Oft genug liest man in irgendwelchen Foren von Leuten, die sich die Zeit direkt bei der PTB holen. Das ist bei einer hierarchisch gedachten Architektur wie NTP aber nicht sinnvoll, da es die zentralen Knoten übermäßig beansprucht. Der Hinweis auf den NTP-Pool im Artikel ist genau das Richtige, nur daß etwas deutlicher darauf hingewiesen werden könnte, daß das die geeignete Zeitquelle für jedermann ist. --RGR (Diskussion) 14:30, 4. Aug. 2015 (CEST)

Unterteilung in gesicherte und ungesicherte NTP Varianten

* ungesichert:

• NTP, UDP Port 123
• SNTP

* gesichert:

• TLSDate https://linux-audit.com/tlsdate-the-secure-alternative-for-ntpd-ntpdate-and-rdate/
• NTS
• NTP over TLS https://datatracker.ietf.org/doc/draft-ietf-ntp-using-nts-for-ntp/
• NTP over HTTPS

* keine Ahnung ob gesichert

• NTPsec, UDP Port 123 https://docs.ntpsec.org/latest/mode6.html
• Ntimed
• chrony
• openntpd--185.183.104.139 00:40, 12. Sep. 2018 (CEST)

Anbieter von NTPsec

Im Artikel fehlt eine Auflistung zu z.B. drei Zeitservern die NTPsec unterstützen.--185.159.157.10 17:55, 18. Feb. 2018 (CET)

Alternativen zum Zeitbezug für IT Systeme per Internet

• Bezug von Zeitsignal per GPS
• Bezug von Zeitsignal per Funk, wie zB. DCF 77 --185.183.104.139 03:49, 28. Jun. 2018 (CEST)

Sehe ich nicht wirklich als Alternative: In einem Netzwerk mit mehreren PCs oder ähnlichem müsste dann jeder PC einen eigenen GPS Empfänger haben. So hat heutzutage meist der NTP Server ein GPS Empfänger und verteilt dann die Zeit. Dies ist Kostengünstiger und weniger Installationsaufwand. --GodeNehler (Diskussion) 20:01, 1. Jul. 2018 (CEST)

Wenn der Router die Zeit für das Netzwerk bereit stellt, benötigt nicht jeder Rechner einen GPS oder DCF 77 Empfänger.--185.183.104.139 00:53, 1. Aug. 2018 (CEST)

"OpenNTPD" ist eine weitere Alternative zu NTP --185.183.104.139 12:54, 4. Aug. 2018 (CEST)

NTS, the NTP replacement are missing on article

• NTS basiert auf NTP, welches durch einen TLS Layer erweitert wurde.
• NTS ist verabschiedet unter der RFC 8915, https://tools.ietf.org/html/rfc8915
• NTS wird z.B. angeboten durch https://www.cloudflare.com/time/ (nicht signierter Beitrag von 92.208.243.129 (Diskussion) 11:48, 26. Mär. 2021 (CET))

erledigtErledigt Das sollte mittlerweile erledigt sein; siehe Abschnitt „NTS“ im Artikel „Network Time Protocol“. (Ein eigenständiger Artikel „Network Time Security“ fehlt derzeit allerdings noch.) Grüße --SweetWood (Diskussion) 09:02, 3. Jan. 2022 (CET)