25
Wenn man in Tokio einen Server dem NTP-Pool hinzufügt
Moin!
Freunde der gepflegten Graphen und Daten!
Die meisten von euch werden sicherlich mal als Zeitserver eine Adresse wie "pool.ntp.org" oder eine der Subdomains eingetragen haben. Oder es war voreingetragen. Oder ihr habt Geräte (Fernseher, Router, Smartphone, ...) die hardcoded diese Zeitserver verwenden.
Bei diesem NTP-Pool kann jeder mitmachen und seine Server bereitstellen. Die Server werden auf Erreichbarkeit und richtige Uhrzeit überwacht und die IP-Adresse des Server wird dann irgendwann ausgeliefert, wenn man in der Region des Servers nach "pool.ntp.org" fragt.
Geht einfach mal davon aus, dass ihr alle irgendetwas habt, was nur wegen dem NTP-Pool und den freiwilligen Enthusiasten, die Server bereitstellen, eine aktuelle und richtige Uhrzeit hat.
Nun gibt es sehr gut versorgte Regionen wie Deutschland, Frankreich, Niederlande, wo jeweils mehrere hundert Pool-Server verfügbar sind. Da die Last recht gut verteilt wird, bekommt dann jeder einzelne Server eine überschaubare Anzahl Anfragen. Meine NTP-Server in Deutschland bekommen jeweils so 200-400 Anfragen pro Sekunde, vieles auch aus benachbarten Ländern.
Und dann gibt es krass unterversorgte Regionen, wo zig Millionen Geräte auf eine handvoll Server treffen.
Indien, China, Brasilien und Japan sind solche. Wo es in Deutschland über 500 Server im Pool gibt, sind es in Indien und Japan nur jeweils 25.
Mein Server in Mumbai bekommt über den NTP-Pool so etwa 35.000 Anfragen pro Sekunde. Je nach Tageszeit sind dann aber auch schon eine Menge Anfragen aus China mit dabei.
Damit ist der Server nicht ausgelastet und er hat noch gut Ressourcen für die Hauptaufgabe übrig - aber lange Zeit habe ich das nur staunend in den Statistiken angesehen.
Dann kam gestern ein Server in Tokio dazu - eine, wir erinnern uns, ebenfalls deutlich unterversorgte Region.
Als der Server dann Freitag Mittag in den Pool aufgenommen wurde, war das dann doch grob beeindruckend:
Hundertfünfzigtausend Anfragen pro Sekunde und 100 Mbps Traffic. Nur für die Uhrzeit!
Auch hier sind Anfragen aus China dabei, der Anteil bewegt sich aber im einstelligen Prozentbereich.
Die Uhrzeiten am Graphen sind UTC, Japan ist UTC+0900. Der Peak gegen 13:00Z / 22:00 JST dürfte daher wohl mit Geräten in Privathaushalten zu erklären sein.
Der IPv6-Anteil der Anfragen liegt aktuell bei bis zu 2%, was ungewöhnlich niedrig ist. In allen Regionen, in denen ich Server habe, ist der IPv6-Anteil der Anfragen bei wenigstens 10%, eher mehr.
Japan hat eine IPv6-Adaption von ca. 45-50% (je nach Quelle), es sollte also vergleichbare IPv6-Anfrageraten geben wie in Deutschland oder Indien.
Dass dies nicht der Fall ist, erkläre ich mir (ohne Beweise) mit irgendwelchen IoT-Geräten, die schlicht nur IPv4 können, dafür aber vermutlich in einigen Häusern zahlreich zu finden sein werden.
Freunde der gepflegten Graphen und Daten!
Die meisten von euch werden sicherlich mal als Zeitserver eine Adresse wie "pool.ntp.org" oder eine der Subdomains eingetragen haben. Oder es war voreingetragen. Oder ihr habt Geräte (Fernseher, Router, Smartphone, ...) die hardcoded diese Zeitserver verwenden.
Bei diesem NTP-Pool kann jeder mitmachen und seine Server bereitstellen. Die Server werden auf Erreichbarkeit und richtige Uhrzeit überwacht und die IP-Adresse des Server wird dann irgendwann ausgeliefert, wenn man in der Region des Servers nach "pool.ntp.org" fragt.
Geht einfach mal davon aus, dass ihr alle irgendetwas habt, was nur wegen dem NTP-Pool und den freiwilligen Enthusiasten, die Server bereitstellen, eine aktuelle und richtige Uhrzeit hat.
Nun gibt es sehr gut versorgte Regionen wie Deutschland, Frankreich, Niederlande, wo jeweils mehrere hundert Pool-Server verfügbar sind. Da die Last recht gut verteilt wird, bekommt dann jeder einzelne Server eine überschaubare Anzahl Anfragen. Meine NTP-Server in Deutschland bekommen jeweils so 200-400 Anfragen pro Sekunde, vieles auch aus benachbarten Ländern.
Und dann gibt es krass unterversorgte Regionen, wo zig Millionen Geräte auf eine handvoll Server treffen.
Indien, China, Brasilien und Japan sind solche. Wo es in Deutschland über 500 Server im Pool gibt, sind es in Indien und Japan nur jeweils 25.
Mein Server in Mumbai bekommt über den NTP-Pool so etwa 35.000 Anfragen pro Sekunde. Je nach Tageszeit sind dann aber auch schon eine Menge Anfragen aus China mit dabei.
Damit ist der Server nicht ausgelastet und er hat noch gut Ressourcen für die Hauptaufgabe übrig - aber lange Zeit habe ich das nur staunend in den Statistiken angesehen.
Dann kam gestern ein Server in Tokio dazu - eine, wir erinnern uns, ebenfalls deutlich unterversorgte Region.
Als der Server dann Freitag Mittag in den Pool aufgenommen wurde, war das dann doch grob beeindruckend:
Hundertfünfzigtausend Anfragen pro Sekunde und 100 Mbps Traffic. Nur für die Uhrzeit!
Auch hier sind Anfragen aus China dabei, der Anteil bewegt sich aber im einstelligen Prozentbereich.
Die Uhrzeiten am Graphen sind UTC, Japan ist UTC+0900. Der Peak gegen 13:00Z / 22:00 JST dürfte daher wohl mit Geräten in Privathaushalten zu erklären sein.
Der IPv6-Anteil der Anfragen liegt aktuell bei bis zu 2%, was ungewöhnlich niedrig ist. In allen Regionen, in denen ich Server habe, ist der IPv6-Anteil der Anfragen bei wenigstens 10%, eher mehr.
Japan hat eine IPv6-Adaption von ca. 45-50% (je nach Quelle), es sollte also vergleichbare IPv6-Anfrageraten geben wie in Deutschland oder Indien.
Dass dies nicht der Fall ist, erkläre ich mir (ohne Beweise) mit irgendwelchen IoT-Geräten, die schlicht nur IPv4 können, dafür aber vermutlich in einigen Häusern zahlreich zu finden sein werden.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 5070029572
Url: https://administrator.de/contentid/5070029572
Printed on: May 2, 2024 at 02:05 o'clock
25 Comments
Latest comment
Moin @LordGurke,
xix da, wir konfigurieren überall wo es geht, die gute deutsche Braunschweiger Atomuhr. 🤪
https://www.ptb.de/cms/ptb/fachabteilungen/abtq/gruppe-q4/ref-q42/zeitsy ...
Uii, was sehe ich da, bei PTB ist ja auch ein weiterer NTP Server dazugekommen, nice.
Hardcoded ... 😬 ... bösses Zeug ... zumindest aus der IT-Security-Sicht gesehen. 😱
Aber ja, dagegen gibt es an der FG/SGW zum Glück sowas wie NAT. Damit kann man die unwilligen Clients, dennoch ratz fatz auf den gewünschten NTP umfuchsen. 🤪
Was den Rest angeht ... 👍👍👍 ... sehr interessanter Artikel.
Beste Grüsse aus BaWü
Alex
Die meisten von euch werden sicherlich mal als Zeitserver eine Adresse wie "pool.ntp.org" oder eine der Subdomains eingetragen haben.
xix da, wir konfigurieren überall wo es geht, die gute deutsche Braunschweiger Atomuhr. 🤪
https://www.ptb.de/cms/ptb/fachabteilungen/abtq/gruppe-q4/ref-q42/zeitsy ...
Uii, was sehe ich da, bei PTB ist ja auch ein weiterer NTP Server dazugekommen, nice.
Oder es war voreingetragen. Oder ihr habt Geräte (Fernseher, Router, Smartphone, ...) die hardcoded diese Zeitserver verwenden.
Hardcoded ... 😬 ... bösses Zeug ... zumindest aus der IT-Security-Sicht gesehen. 😱
Aber ja, dagegen gibt es an der FG/SGW zum Glück sowas wie NAT. Damit kann man die unwilligen Clients, dennoch ratz fatz auf den gewünschten NTP umfuchsen. 🤪
Was den Rest angeht ... 👍👍👍 ... sehr interessanter Artikel.
Beste Grüsse aus BaWü
Alex
wir konfigurieren überall wo es geht, die gute deutsche Braunschweiger Atomuhr.
Das hat die PTB aber mittlerweile untersagt und sollte man aus guten Gründen nicht mehr tun!! 🧐https://www.heise.de/ratgeber/oeffentliche-Zeitquellen-322978.html
Vielleicht mal ein guter Vorsatz für das neue Jahr! 🎄
Moin aqui,
https://www.heise.de/ratgeber/oeffentliche-Zeitquellen-322978.html
Vielleicht mal ein guter Vorsatz für das neue Jahr! 🎄
ähm, du möchtest mich jetzt aber nicht mit einem komplett veralteten Heise Artikel aus dem Jahr 2007, der zudem niemals von der PTB selbst bestätigt wurde, ernsthaft zu einem guten Vorsatz bewegen. 🤨
Ausserdem hat mein Hausdrachen mein sämtliches Kontingent an guten Vorsätzen eh schon aufgefressen. 🤪
Wie auch immer.
Habe ein schönes Weihnachtsfest und einen guten Rutsch ins neue Jahr.
Beste Grüsse aus Murrhardt
Alex
wir konfigurieren überall wo es geht, die gute deutsche Braunschweiger Atomuhr.
Das hat die PTB aber mittlerweile untersagt und sollte man aus guten Gründen nicht mehr tun!! 🧐https://www.heise.de/ratgeber/oeffentliche-Zeitquellen-322978.html
Vielleicht mal ein guter Vorsatz für das neue Jahr! 🎄
ähm, du möchtest mich jetzt aber nicht mit einem komplett veralteten Heise Artikel aus dem Jahr 2007, der zudem niemals von der PTB selbst bestätigt wurde, ernsthaft zu einem guten Vorsatz bewegen. 🤨
Ausserdem hat mein Hausdrachen mein sämtliches Kontingent an guten Vorsätzen eh schon aufgefressen. 🤪
Wie auch immer.
Habe ein schönes Weihnachtsfest und einen guten Rutsch ins neue Jahr.
Beste Grüsse aus Murrhardt
Alex
Zitat von @aqui:
https://www.heise.de/ratgeber/oeffentliche-Zeitquellen-322978.html
Vielleicht mal ein guter Vorsatz für das neue Jahr! 🎄
wir konfigurieren überall wo es geht, die gute deutsche Braunschweiger Atomuhr.
Das hat die PTB aber mittlerweile untersagt und sollte man aus guten Gründen nicht mehr tun!! 🧐https://www.heise.de/ratgeber/oeffentliche-Zeitquellen-322978.html
Vielleicht mal ein guter Vorsatz für das neue Jahr! 🎄
Das stimmt so nicht, iiirc. Die PTB, sagt, man soll nicht für jeden Furz deren Server nehmen, sondern nur einen eigenen Server mit denen abgleichen alle anderen eigenen Maschinen sollen sich dann bitte die Zeit vom eigenen Server holen, was ja durchaus nachvollziehbar ist und auch technisch trivial umsetzbar.
lks
Zitat von @MysticFoxDE:
Moin aqui,
https://www.heise.de/ratgeber/oeffentliche-Zeitquellen-322978.html
Vielleicht mal ein guter Vorsatz für das neue Jahr! 🎄
ähm, du möchtest mich jetzt aber nicht mit einem komplett veralteten Heise Artikel aus dem Jahr 2007, der zudem niemals von der PTB selbst bestätigt wurde, ernsthaft zu einem guten Vorsatz bewegen. 🤨
Moin aqui,
wir konfigurieren überall wo es geht, die gute deutsche Braunschweiger Atomuhr.
Das hat die PTB aber mittlerweile untersagt und sollte man aus guten Gründen nicht mehr tun!! 🧐https://www.heise.de/ratgeber/oeffentliche-Zeitquellen-322978.html
Vielleicht mal ein guter Vorsatz für das neue Jahr! 🎄
ähm, du möchtest mich jetzt aber nicht mit einem komplett veralteten Heise Artikel aus dem Jahr 2007, der zudem niemals von der PTB selbst bestätigt wurde, ernsthaft zu einem guten Vorsatz bewegen. 🤨
Die PTB sagt aber, daß man nicht generell deren Server nehmen soll, sonder eigene und nur einen von denen mit der PTB abgleichen.
lks
Wir haben in jeder Zeitzone wo wir produzieren zwei Meinberg Uhren als Cluster.
Wir synchronisieren gegen time.google.com
Wir synchronisieren gegen time.google.com
1
Ich bin einigermaßen verwirrt, dass eine Industrienation wie Japan nur so wenige Server im Pool hat 🤔
Manuel
Manuel
Zitat von @manuel-r:
Ich bin einigermaßen verwirrt, dass eine Industrienation wie Japan nur so wenige Server im Pool hat 🤔
Ich bin einigermaßen verwirrt, dass eine Industrienation wie Japan nur so wenige Server im Pool hat 🤔
Wenn man nicht mehr braucht. Warum sollte man dann?
lks
Zitat von @manuel-r:
Ich bin einigermaßen verwirrt, dass eine Industrienation wie Japan nur so wenige Server im Pool hat 🤔
Manuel
Ich bin einigermaßen verwirrt, dass eine Industrienation wie Japan nur so wenige Server im Pool hat 🤔
Manuel
Das sagt ja nichts aus. Vielleicht haben sie eine vorbildliche Infrastruktur und kommen so gut hin.
Zitat von @Lochkartenstanzer:
Wenn man nicht mehr braucht. Warum sollte man dann?
lks
Zitat von @manuel-r:
Ich bin einigermaßen verwirrt, dass eine Industrienation wie Japan nur so wenige Server im Pool hat 🤔
Ich bin einigermaßen verwirrt, dass eine Industrienation wie Japan nur so wenige Server im Pool hat 🤔
Wenn man nicht mehr braucht. Warum sollte man dann?
lks
Wenn ich @LordGurke richtig verstehe, dann hat er einen Server zum Pool hinzugefügt und damit unmittelbar 150.000 Anfragen/s beantwortet. Für mich heißt das es wurde sehr wohl ein weiterer Server (besser noch ein paar) im Pool benötigt. Ansonsten hätte er keine oder zumindest deutlich weniger als 150.000 Anfragen beantwortet.
Manuel
Zitat von @2423392070:
Das sagt ja nichts aus. Vielleicht haben sie eine vorbildliche Infrastruktur und kommen so gut hin.
Zitat von @manuel-r:
Ich bin einigermaßen verwirrt, dass eine Industrienation wie Japan nur so wenige Server im Pool hat 🤔
Manuel
Ich bin einigermaßen verwirrt, dass eine Industrienation wie Japan nur so wenige Server im Pool hat 🤔
Manuel
Das sagt ja nichts aus. Vielleicht haben sie eine vorbildliche Infrastruktur und kommen so gut hin.
Scheinbar nicht. Wäre die Infrastruktur völlig ausreichend gewesen würde der Server von @LordGurke sich langweilen. Tut er aber nicht.
Manuel
Weil 150k Anfragen bei 100MBit...
Sorry, aber das ist doch keine nennenswerte Last.
Sorry, aber das ist doch keine nennenswerte Last.
Zitat von @2423392070:
Weil 150k Anfragen bei 100MBit...
Sorry, aber das ist doch keine nennenswerte Last.
Weil 150k Anfragen bei 100MBit...
Sorry, aber das ist doch keine nennenswerte Last.
Für einen NTP-Dienst, der ja nur "nebenbei" existieren soll, ist das schon recht beeindruckend. Zumindest gemessen an der Tatsache, dass chronyd innerhalb einer Stunde rund 80 Minuten CPU-Zeit auf einem AMD Epyc 7542 beansprucht, also mehr als einen Kern dauerhaft auslastet.
Zitat von @2423392070:
Wir haben in jeder Zeitzone wo wir produzieren zwei Meinberg Uhren als Cluster.
Wir synchronisieren gegen time.google.com
Wir haben in jeder Zeitzone wo wir produzieren zwei Meinberg Uhren als Cluster.
Wir synchronisieren gegen time.google.com
Oh, das hätte in der Vergangenheit interessante Probleme in der Nähe von Schaltsekunden (die ja ausgesetzt wurden) bringen können.
Google nutzt ein eigenes System für "time skewing" um keine harte doppelte Sekunde zu haben sondern die Zeit auf dem System vor der Schaltsekunde etwas schnell und dahinter etwas langsamer laufen zu lassen, bis der Unterschied ausgeglichen ist.
Für ungefähr anderthalb Tage hast du dann einen Versatz von 100-300 ms zwischen Systemen, die ausschließlich gegen Google synchronisieren und denen, die gegen andere Zeitquellen (DCF, GPS...) synchronisieren.
Innerhalb von Clustern, die auf präzise identische Uhrzeit angewiesen sind, synchronisiert man ja normal alle beteiligten Systeme gegen die selben Zeitquellen und hat kein Problem mit solchen Abweichungen.
Das wird erst ein Problem, wenn man Systeme zusammenbringt, die unterschiedliche Quellen benutzen.
1Zitat von @manuel-r:
Ich bin einigermaßen verwirrt, dass eine Industrienation wie Japan nur so wenige Server im Pool hat 🤔
Ich bin einigermaßen verwirrt, dass eine Industrienation wie Japan nur so wenige Server im Pool hat 🤔
Der Hauptfaktor für sowas ist, wie viele Anbieter für Serverhosting es in einem Land gibt und was es kostet.
Ich zähle bei sowas explizit keine Anbieter wie OVH oder Ionos mit, die ihre Dienste in vielen Ländern anbieten und sich teilweise auch primär an nicht in Japan sitzende Kunden richten.
Die Anbieter, die ich gefunden habe, haben alle gemeinsam, dass sie entweder nur 100 Mbps unmetered oder höhere Portgeschwindigkeiten, dafür aber mit Abrechnung des Traffics anbieten.
100 Mbps, das sehen wir, reichen da nicht wirklich aus, wenn man noch was anderes mit dem Server nebenher vorhat. Alternative: Irgendwas mit 5-8 TB Inklusivvolumen, was aber binnen weniger Tage aufgebraucht wäre.
Bei dedizierten Servern habe ich hauptsächlich Sakura als Anbieter gefunden, die für 250 Mbps "Global Line" eine zusätzliche Gebühr von 28.600 円 erheben, umgerechnet rund 200 €. Sonst sind es nur 50 Mbps Außenanbindung.
Sakura ist generell nicht der günstigste Anbieter, hat aber nach unseren Tests auch die besseren Anbindungen gehabt. Japan ist, was das angeht, relativ fest in der Hand von NTT, speziell was globalen Transit angeht. Leider ist bei NTT nicht die Frage, ob es Packetloss zu einem Ziel gibt, sondern nur wann. Irgendwas ist da leider immer...
Machen wir uns nichts vor - was Serverhosting angeht, sind wir in Deutschland ziemlich verwöhnt.
Hier bekommst du für durchschnittlich 50-60 € einen dedicated Server mit Gigabit unmetered.
Die Preise für vServer zwischen Japan und Deutschland sind zwar ziemlich vergleichbar, aber auch hier eigentlich fast überall mit Gigabit unmetered mittlerweile.
Aber davon abgesehen muss es eigentlich noch weitere Gründe haben. In Europa sind über 3.000 Pool-Server verfügbar, in Nordamerika "nur" 1.040 und in ganz Asien gerade einmal um die 330. Das *kann*, wenn man mal die USA betrachtet, eigentlich nicht nur an Preis oder Verfügbarkeit liegen.
Eingedenk der Tatsache, dass dies Indien, Hong-Kong, Singapur, Japan, Taiwan... einschließt, ist das schon vergleichsweise wenig. Das bedeutet dann mehr Last für die dortigen Server, das macht es für Hobbyisten schwieriger, da einen Server bereitzustellen.
2
Moin lks,
das machen ich natürlich im Normalfall auch so.
Sprich, die Clients synchronisieren gegen die ADDS Server, die ADDS Server synchronisieren gegen die FW/SGW und dieses wiederum synchronisiert dann gegen Braunschweig. 😁
Beste Grüsse aus Murrhardt
Alex
Die PTB sagt aber, daß man nicht generell deren Server nehmen soll, sonder eigene und nur einen von denen mit der PTB abgleichen.
das machen ich natürlich im Normalfall auch so.
Sprich, die Clients synchronisieren gegen die ADDS Server, die ADDS Server synchronisieren gegen die FW/SGW und dieses wiederum synchronisiert dann gegen Braunschweig. 😁
Beste Grüsse aus Murrhardt
Alex
Zitat von @aqui:
https://www.heise.de/ratgeber/oeffentliche-Zeitquellen-322978.html
Vielleicht mal ein guter Vorsatz für das neue Jahr! 🎄
wir konfigurieren überall wo es geht, die gute deutsche Braunschweiger Atomuhr.
Das hat die PTB aber mittlerweile untersagt und sollte man aus guten Gründen nicht mehr tun!! 🧐https://www.heise.de/ratgeber/oeffentliche-Zeitquellen-322978.html
Vielleicht mal ein guter Vorsatz für das neue Jahr! 🎄
Nö, die Bundesanstalt bietet den Service weiterhin kostenlos an:
https://www.ptb.de/cms/ptb/fachabteilungen/abtq/gruppe-q4/ref-q42/zeitsy ...
Dann hat sich die PTB Policy vermutlich wieder geändert?! So oder so ist es aber nicht gut einen dedizierten Server zu verwenden und denn ggf. zu überlasten sondern den NTP Pool de.pool.ntp zu nutzen um eine homogene Verteilung auf die NTP Server zu erreichen. Kollege @LordGurke hatte das oben ja schon angesprochen.
Moin aqui,
wenn der PTB einknickt, dann haben viele andere NTP-Server in Deutschland ebenfalls ein Problem, da diese meisten selbst gegen den PTB synchronisieren, weil das PTB mit seinen vier primären Caesium-Atomuhren, nun mal die genaueste Zeitquelle in Deutschland ist.
Gruss Alex
Dann hat sich die PTB Policy vermutlich wieder geändert?! So oder so ist es aber nicht gut einen dedizierten Server zu verwenden und denn ggf. zu überlasten sondern den NTP Pool de.pool.ntp zu nutzen um eine homogene Verteilung auf die NTP Server zu erreichen. Kollege @LordGurke hatte das oben ja schon angesprochen.
wenn der PTB einknickt, dann haben viele andere NTP-Server in Deutschland ebenfalls ein Problem, da diese meisten selbst gegen den PTB synchronisieren, weil das PTB mit seinen vier primären Caesium-Atomuhren, nun mal die genaueste Zeitquelle in Deutschland ist.
Gruss Alex
Ich erinnere mich auch, dass das PTB explizit nur die Synchronisation von Stratum 2-Uhren erlaubt hat, auch wenn ich dazu nichts mehr auf deren Webseite finde. Man sollte deren Zeitserver nicht direkt von allen möglichen Clients abfragen sondern nur auf deinen eigenen NTP-Servern, die dann die Zeit weitergeben. Eben, um die PTB-Server nicht unnötig zu belasten.
Einen Stratum 2-Server anstelle des PTB (oder jeder anderen Stratum 1-Uhr) zu verwenden hat auch keinen Nachteil. Die Zeit ist die gleiche
Einen Stratum 2-Server anstelle des PTB (oder jeder anderen Stratum 1-Uhr) zu verwenden hat auch keinen Nachteil. Die Zeit ist die gleiche
1Zitat von @LordGurke:
Ich erinnere mich auch, dass das PTB explizit nur die Synchronisation von Stratum 2-Uhren erlaubt hat, auch wenn ich dazu nichts mehr auf deren Webseite finde. Man sollte deren Zeitserver nicht direkt von allen möglichen Clients abfragen sondern nur auf deinen eigenen NTP-Servern, die dann die Zeit weitergeben. Eben, um die PTB-Server nicht unnötig zu belasten.
Einen Stratum 2-Server anstelle des PTB (oder jeder anderen Stratum 1-Uhr) zu verwenden hat auch keinen Nachteil. Die Zeit ist die gleiche
Ich erinnere mich auch, dass das PTB explizit nur die Synchronisation von Stratum 2-Uhren erlaubt hat, auch wenn ich dazu nichts mehr auf deren Webseite finde. Man sollte deren Zeitserver nicht direkt von allen möglichen Clients abfragen sondern nur auf deinen eigenen NTP-Servern, die dann die Zeit weitergeben. Eben, um die PTB-Server nicht unnötig zu belasten.
Einen Stratum 2-Server anstelle des PTB (oder jeder anderen Stratum 1-Uhr) zu verwenden hat auch keinen Nachteil. Die Zeit ist die gleiche
Jupp. Ich meine auch, daß das zumindest früher auf deren Webseiten stand. Und ja, Das sollte die übliche Strategie sein, nur die ntp-server mit der ptb abzugleichen und die Clients dann mit den eigenen Servern.
lks
Moin @LordGurke,
Wenn ich das richtig in Erinnerung habe, dann hat der PTB sogar den Zugriff auf seine Stratum 1-Uhren erlaubt.
Der Ansicht ist auch die Heise in dem folgenden Artikel, in welchen sie übrigens von der zuvor berichteten Abschaltung wieder zurückrudert.
https://www.heise.de/ratgeber/Genaue-Zeit-fuer-alle-323080.html
Und auch der Bund empfiehlt die Zeitsynchronisation über das PTB.
https://www.service.bund.de/Content/DE/DELeistungen/XYZ/Zeitdienst-Onlin ...
Das ist korrekt, gilt aber nicht nur für die Synchronisation gegen das PTB sondern eher generell.
Kommt ganz auf die Geschwindigkeit an, mit der man durch die Gegend flitzt. 🤪
Aber ja, 99,99% der Anwender/Anwendungen, würden selbst bei einem Sync gegen eine Stratum 100-Uhr, wahrscheinlich nicht wirklich was merken.
Mit besten Zwischenjahresgrüssen aus BaWü
Alex
Ich erinnere mich auch, dass das PTB explizit nur die Synchronisation von Stratum 2-Uhren erlaubt hat, auch wenn ich dazu nichts mehr auf deren Webseite finde.
Wenn ich das richtig in Erinnerung habe, dann hat der PTB sogar den Zugriff auf seine Stratum 1-Uhren erlaubt.
Der Ansicht ist auch die Heise in dem folgenden Artikel, in welchen sie übrigens von der zuvor berichteten Abschaltung wieder zurückrudert.
https://www.heise.de/ratgeber/Genaue-Zeit-fuer-alle-323080.html
Und auch der Bund empfiehlt die Zeitsynchronisation über das PTB.
https://www.service.bund.de/Content/DE/DELeistungen/XYZ/Zeitdienst-Onlin ...
Man sollte deren Zeitserver nicht direkt von allen möglichen Clients abfragen sondern nur auf deinen eigenen NTP-Servern, die dann die Zeit weitergeben. Eben, um die PTB-Server nicht unnötig zu belasten.
Das ist korrekt, gilt aber nicht nur für die Synchronisation gegen das PTB sondern eher generell.
Einen Stratum 2-Server anstelle des PTB (oder jeder anderen Stratum 1-Uhr) zu verwenden hat auch keinen Nachteil. Die Zeit ist die gleiche
Kommt ganz auf die Geschwindigkeit an, mit der man durch die Gegend flitzt. 🤪
Aber ja, 99,99% der Anwender/Anwendungen, würden selbst bei einem Sync gegen eine Stratum 100-Uhr, wahrscheinlich nicht wirklich was merken.
Mit besten Zwischenjahresgrüssen aus BaWü
Alex
Bei NTP sollte man das genauso handhaben wie bei DNS, immer der Hierarchie folgen...
Bei mir Zuhause funkt die Fritzbox gegen PTB und die dahinterliegenden Clients gegen die Box.
Mein IOT-Netz gegen den IOT-Netz-Router usw.
Bei Kunden frage ich auch immer nach Zeitserver, und bei jüngeren Kollegen stoße ich da meistens auf fragende Gesichter. Die älteren fragen nach RFC 868 (TIME/ITP) oder RFC 1769 (NTP)
VG
bitnarrator
Bei mir Zuhause funkt die Fritzbox gegen PTB und die dahinterliegenden Clients gegen die Box.
Mein IOT-Netz gegen den IOT-Netz-Router usw.
Bei Kunden frage ich auch immer nach Zeitserver, und bei jüngeren Kollegen stoße ich da meistens auf fragende Gesichter. Die älteren fragen nach RFC 868 (TIME/ITP) oder RFC 1769 (NTP)
VG
bitnarrator
Zitat von @LordGurke:
Oh, das hätte in der Vergangenheit interessante Probleme in der Nähe von Schaltsekunden (die ja ausgesetzt wurden) bringen können.
Google nutzt ein eigenes System für "time skewing" um keine harte doppelte Sekunde zu haben sondern die Zeit auf dem System vor der Schaltsekunde etwas schnell und dahinter etwas langsamer laufen zu lassen, bis der Unterschied ausgeglichen ist.
Für ungefähr anderthalb Tage hast du dann einen Versatz von 100-300 ms zwischen Systemen, die ausschließlich gegen Google synchronisieren und denen, die gegen andere Zeitquellen (DCF, GPS...) synchronisieren.
Innerhalb von Clustern, die auf präzise identische Uhrzeit angewiesen sind, synchronisiert man ja normal alle beteiligten Systeme gegen die selben Zeitquellen und hat kein Problem mit solchen Abweichungen.
Das wird erst ein Problem, wenn man Systeme zusammenbringt, die unterschiedliche Quellen benutzen.
Zitat von @2423392070:
Wir haben in jeder Zeitzone wo wir produzieren zwei Meinberg Uhren als Cluster.
Wir synchronisieren gegen time.google.com
Wir haben in jeder Zeitzone wo wir produzieren zwei Meinberg Uhren als Cluster.
Wir synchronisieren gegen time.google.com
Oh, das hätte in der Vergangenheit interessante Probleme in der Nähe von Schaltsekunden (die ja ausgesetzt wurden) bringen können.
Google nutzt ein eigenes System für "time skewing" um keine harte doppelte Sekunde zu haben sondern die Zeit auf dem System vor der Schaltsekunde etwas schnell und dahinter etwas langsamer laufen zu lassen, bis der Unterschied ausgeglichen ist.
Für ungefähr anderthalb Tage hast du dann einen Versatz von 100-300 ms zwischen Systemen, die ausschließlich gegen Google synchronisieren und denen, die gegen andere Zeitquellen (DCF, GPS...) synchronisieren.
Innerhalb von Clustern, die auf präzise identische Uhrzeit angewiesen sind, synchronisiert man ja normal alle beteiligten Systeme gegen die selben Zeitquellen und hat kein Problem mit solchen Abweichungen.
Das wird erst ein Problem, wenn man Systeme zusammenbringt, die unterschiedliche Quellen benutzen.
Der Punkt ist, dass nichts zusammen gebracht wird.
Das Meinberg Cluster sendet in den Zeitzonen, daher auch für jede Zeitzone ein eigenes Cluster, die "spoofed local time"
Das machen wir, weil wir von den SPS Programmiern keine Handstände für die Uhrzeit sehen wollen und maximal eine Sekunde pro Site an Versatz haben wollen. Das Meinberg Cluster hat eine ACL um ausgewählte Clients zu bedienen.
Der "Rest" findet seine Zeit in den Domain-Controllern. Ausgehende Anfragen, das kommt hin und wieder Mal vor, Schreiben wir per NAT um.auf unsere DCs.
Zwischen Meinberger und DCs ist der Versatz kleiner 1 Sekunde. Das reicht um die Qualität von Zeitstempel, in z. B. Logs, sicherzustellen.
Ein AMD Epyc 7542 hat wie viele Kerne? 32? 64?
Ich denke die Dichte der Server und Anfragen, kann so wie geschehen nicht verglichen werden.
Weniger Server mit höherer Last sollte bevorzugt die running config sein.
Zitat von @2423392070:
Ein AMD Epyc 7542 hat wie viele Kerne? 32? 64?
Ein AMD Epyc 7542 hat wie viele Kerne? 32? 64?
Die Betonung lag darauf, dass der Server das als Dient nebenbei anbietet. Quasi als Abfallprodukt. Das war zumindest unerwartet viel CPU-Last, wenn natürlich auch nicht problematisch. Das ist eher der anfallende Traffic.
Ich denke die Dichte der Server und Anfragen, kann so wie geschehen nicht verglichen werden.
Weniger Server mit höherer Last sollte bevorzugt die running config sein.
Weniger Server mit höherer Last sollte bevorzugt die running config sein.
Jaein. Das gilt, wenn du wirklich alles unter deiner Kontrolle hast. Im Internet hast du leider hin und wieder das Problem, dass NTP-Traffic von irgendwelchen Providern oder Tier1-Carriern gefiltert wird. Natürlich ohne dass das irgendwie kommuniziert wird.
Hintergrund davon ist bisher immer gewesen, dass man DDoS-Attacken durch NTP-Monlist filtern wollte. Kollateralschäden dieser Art ließen sich an sich einfach vermeiden (durch Filterung auf Paketgröße), aber erst vor ein paar Monaten habe ich wieder so ein Gespräch darüber mit Lumen (früher Level3) geführt...
Wenn du dann eine größere Auswahl von Servern mit entsprechend hoher Disjunktivität an Anbindungen und Transits hast, reduzierst du Störungen dieser Art ganz gut.
