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.
Please also mark the comments that contributed to the solution of the article
Content-ID: 5070029572
Url: https://administrator.de/contentid/5070029572
Printed on: October 5, 2024 at 03:10 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
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.
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
Zitat 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.