Diskussion:Network Time Protocol

message: 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? --JoBa2282 Red mit mir 07:41, 17. Sep. 2009 (CEST)
thread_title:  Finding A Time Server 

message: 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)
thread_title: Weblinks

message: 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. --JoBa2282 Red mit mir 07:43, 17. Sep. 2009 (CEST)
thread_title:  Keine Zeitzone 

message: 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.
: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 232 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)
replies: text: 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)
replies: text: 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)
thread_title: Nulldurchgang alle 136 Jahre

message: hi,
Plural von Stratum = Strati oder Strata ?
--87.193.229.58 13:48, 22. Jul. 2008 (CEST)
replies: text: 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)
thread_title: Lateinisches

message: 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)
thread_title:  Stratum 

message: 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)
replies: text: 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)
replies: text: Kann das bitte jemand im Artikel ergänzen? Eigentlich stellt es ja dessen Hauptinhalt dar. --Azaël 17:41, 12. Okt. 2009 (CEST)
replies: text: 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)
replies: text:  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)
replies: text: 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)
thread_title:  Also ''wie'' funktioniert das jetzt? 

message: "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)
replies: text: Suche auch eine Quelle dazu. Kann mir vorstellen, dass man besser 1ms erreicht. Alex42 12:28, 22. Mär. 2010 (CET)
thread_title:  Genauigkeit 

message: 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)
thread_title:  offizelle zeitserver 

message: * 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)
thread_title:  Unterteilung in gesicherte und ungesicherte NTP Varianten 

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

message: * Bezug von Zeitsignal per GPS
* Bezug von Zeitsignal per Funk, wie zB. DCF 77 --185.183.104.139 03:49, 28. Jun. 2018 (CEST)
replies: text: 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)
replies: text:  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)
replies: text: "OpenNTPD" ist eine weitere Alternative zu NTP --185.183.104.139 12:54, 4. Aug. 2018 (CEST)
thread_title:  Alternativen zum Zeitbezug für IT Systeme per Internet 

message: * 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/ 
:  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)
thread_title:  NTS, the NTP replacement are missing on article