- Eine Visualisierungsseite, die die Latenzzeiten zwischen AWS-Rechenzentren in drei ms-Bereichen darstellt
- Die Legende ist in unter 100 ms, 100–200 ms und über 200 ms unterteilt, sodass sich das Latenzniveau schnell vergleichen lässt
- Anhand der bereitgestellten Informationen lässt sich nicht feststellen, welche Rechenzentren oder Regionen enthalten sind
- Messmethode, Messzeitpunkt und einzelne Latenzwerte zwischen den Rechenzentren werden nicht angegeben
- Daher ist der in dieser Zusammenfassung überprüfbare Umfang auf die Bereichsgrenzen der Visualisierung beschränkt
Legende der Latenzzeiten
- X < 100ms: unter 100 ms
- X 100ms - 200ms: 100 ms–200 ms
- X > 200ms: über 200 ms
Nicht überprüfbare Details
- Eine Liste bestimmter AWS-Rechenzentren oder Regionsnamen wird nicht bereitgestellt
- Messmethode, Messzeitpunkt und einzelne Latenzwerte zwischen Rechenzentren lassen sich nicht verifizieren
2 Kommentare
us-east-1 scheint also der beste Standort in Richtung Westen zu sein.
Hacker-News-Kommentare
Statt nur Ping-Werte anzuzeigen, wäre es gut, auch zu zeigen, wie schlecht sie im Vergleich zum theoretischen Optimum sind.
Soweit ich weiß, ist die Lichtgeschwindigkeit im Medium Glasfaser etwa 30 % langsamer als Licht im Vakuum.
Es gab mehrfach Fälle, in denen in Architektur-Meetings über die Latenz zwischen Rechenzentren geklagt wurde, sich später aber herausstellte, dass die Werte von vornherein ziemlich nah an dem lagen, was theoretisch möglich ist.
Wenn Kunden Systeme für Hochverfügbarkeit oder Disaster Recovery entwerfen, ist es wichtig zu verhindern, dass sie versehentlich eine primäre Zone und eine Region oder Zone mit „künstlich“ hoher Latenz auswählen.
Mein aktuelles Unternehmen ist auf die Cloud-Migration von SAP spezialisiert, und seit wir in der Vergangenheit aufgrund falscher Annahmen mit inakzeptabler Latenz konfrontiert waren, führen wir dieses Gespräch mit Netzwerkexperten von AWS und GCP zwingend schon in der Angebots- und Scope-Phase.
Es handelt sich nicht um ICMP-Ping, sondern um eine Socket-Stream-Verbindung über tcp/443.
Ping kann als Metrik ungeeignet sein.
https://github.com/mda590/cloudping.co/blob/8918ee8d7e632765...
Licht in Glasfaserkabeln bewegt sich ungefähr mit 70 % der Lichtgeschwindigkeit, also etwa 210.000 km/s.
Der Erdumfang beträgt etwa 40.000 km, und der direkte Weg zur gegenüberliegenden Seite der Erde ergibt ungefähr 100 ms einfache Strecke und etwa 200 ms Roundtrip.
Natürlich könnte man mit Hohlkernfasern und nahezu geradlinigen Glasfaserrouten theoretisch etwa 40 % mehr herausholen, aber nur wenige wären bereit, die Kosten dafür zu tragen.
Ich frage mich, ob es gute Quellen gibt, um diesen Wert genau zu berechnen.
Ich habe eine Rot-Grün-Sehschwäche, daher ist es für mich schwierig oder unmöglich, die Linien für unter 100 ms von denen für über 200 ms zu unterscheiden.
Das betrifft etwa 8 % der männlichen Bevölkerung, daher wäre ein Farbenblind-Modus gut.
Die Visualisierung selbst ist sehr gelungen.
In den Entwicklerwerkzeugen dem
body-Element die Regelfilter: hue-rotate(60deg);hinzufügen oder in der Adressleistejavascript:void(document.body.style.filter='hue-rotate(60deg)')ausführen.Mich würde interessieren, welche Umsetzungen dieses Problem in der Vergangenheit am besten gelöst haben; falls es Links gibt, bitte teilen.
Das ist ziemlich verwirrend.
Also etwa einen Filter, der die Farben des gesamten Bildschirms auf eine bestimmte Weise verändert, damit man sie unterscheiden kann.
Der Anteil ist niedriger, und auch unter farbenblinden Menschen unterscheidet sich die Farbwahrnehmung.
Nur weil etwas für jemanden gut sichtbar ist, heißt das nicht, dass es auch für andere gut sichtbar ist – und umgekehrt ebenso wenig.
Ich habe früher einmal für einen Kunden eine entsprechende Planung gemacht.
Beim Messen der AWS-Latenzen passte es mit den tatsächlichen Latenzen auf 10 % genau, wenn man die grobe Länge der Unterseekabel in Kilometern nahm und durch 150 teilte.
Nicht wirklich überraschend, aber sehr konsistent; später stellte sich heraus, dass es wohl 155 war.
https://www.ibiblio.org/harris/500milemail.html
„Mit LabVIEW wurde die Lichtgeschwindigkeit in einer Glasfaser auf etwa 2,054 x 10^8 m/s berechnet, was einem typischen Wert für den Brechungsindex n ≈ 1,4606 entspricht.“
https://web.phys.ksu.edu/posters/2009/juma-Adv-Lab-S09.pdf
Ich frage mich, ob die mathematische Erklärung dieser Faustregel ungefähr so aussieht:
https://news.ycombinator.com/user?id=Hikikomori hat die Lichtgeschwindigkeit im Glasfasermedium von 3e5 auf 2e5 korrigiert.
Die Lichtgeschwindigkeit beträgt 2e5 km/s, also etwa 2e2 km/ms, und damit ergibt sich die Form Länge(km) / 200(km/ms); letztlich wird daraus Latenz(ms) ≈ K' × Länge(km).
Ich frage mich, ob K hier etwa 1,3 ist, K' 1/155, und ob darin Faktoren wie nicht geradlinige Entfernung, Netzwerk-Overhead und Switching sowie Messfehler beim Roundtrip enthalten sind.
Interessant. Wenn man auf einen blauen Kreis klickt, der ein Rechenzentrum darstellt, wird die Latenz zu anderen Rechenzentren angezeigt.
Ich habe kurz gebraucht, um das herauszufinden; es wäre gut, auf der Site einen Hinweis wie Klicken Sie auf ein Rechenzentrum, um es auszuwählen hinzuzufügen.
Eine Region besteht aus einer Mischung von Netzwerk- und Compute-Komponenten auf mehreren Abstraktionsebenen, also Rechenzentren, Edge-Standorten und Ähnlichem.
Auch innerhalb einer Region kann es je nach Zone große Schwankungen geben, daher ist die Messmethodik wichtig.
AWS stellt im Network Manager Latenzwerte zwischen Regionen, zwischen Availability Zones und innerhalb von Availability Zones bereit.
Das ist nützlich, um eine Latenz-Baseline zu ermitteln und zu sehen, ob es ein Problem auf AWS-Seite gibt.
https://docs.aws.amazon.com/network-manager/latest/infrastru...
Die Visualisierung und das Konzept sind cool, aber es wäre besser, wenn die Farben keine diskreten Bereiche, sondern ein kontinuierlicher Gradient wären.
Die aktuelle Darstellung lässt 100 ms viel schlechter aussehen als 99 ms, aber genauso wie 200 ms.
Wenn man zum Beispiel us-east-1 anklickt, wirken die Latenzen der westeuropäischen Rechenzentren ziemlich unterschiedlich: eu-central-1 und eu-south-1 unterscheiden sich nur um etwa 9 ms, sehen aber völlig verschieden aus, während eu-north-1 und ap-south-1 sich um etwa 88 ms unterscheiden, aber gleich aussehen.
Es gibt auch die Idee, die Messwerte mit der minimal möglichen Latenz relativ zur Lichtgeschwindigkeit zu vergleichen; das Problem ist nur, dass die Lichtgeschwindigkeit c im Vakuum nicht die Ausbreitungsgeschwindigkeit von Information in Glasfaser ist.
Selbst das theoretische Optimum kommt schon allein wegen der Lichtgeschwindigkeit im Medium kaum über 70 % von c hinaus, und dazu kommen viele unbekannte Faktoren wie Repeater-Latenzen.
Die aktuelle Visualisierung lässt eine Latenz von 90 ms wie „gut“ aussehen, obwohl sie für viele Anwendungen in der Praxis völlig inakzeptabel ist.
Besonders dann, wenn zur Verarbeitung einer einzelnen Anfrage mehrere Roundtrips nötig sind.
Ich frage mich, wie ausgewählt wurde, welche Rechenzentren enthalten sind.
Zum Beispiel fehlt Spanien mit eu-south-2.
Ich habe früher an einem Projekt gearbeitet, bei dem die Latenz zwischen Rechenzentren unter 30 ms liegen musste, und wir mussten eu-west-1 in Irland und eu-south-2 verwenden.
Die tatsächliche Latenz lag aber eher bei 42 ms; der Hauptgrund war, dass es kein Seekabel zwischen Irland und dem europäischen Kontinent gibt, sodass der Traffic erst nach Großbritannien gehen und dann quer durch Großbritannien zu einem Kabel Richtung Kontinent geroutet werden musste.
Wenn man zu CloudPing geht, enthält der Datensatz kein eu-south-2.
Im GitHub-Repository von CloudPing gab es seit vier Jahren keine Code-Änderungen mehr, daher könnten seit der letzten aktiven Arbeit daran einige neue Regionen hinzugekommen sein.
Ich möchte rein aus Interesse wissen, wo solche Informationen öffentlich verfügbar sind.
Die Daten sind sehr nützlich und der Globus ist visuell beeindruckend, aber für die praktische Nutzung wäre eine flache Weltkarte vermutlich besser.
Man könnte alle Rechenzentren auf einmal sehen, und weil die Linien nicht so stark zusammenlaufen, wäre es leichter zu lesen.
https://en.wikipedia.org/wiki/Azimuthal_equidistant_projecti...
Eine Option zum Umschalten zwischen beiden wäre besser.
Der größte Faktor für Latenz ist natürlich die Entfernung.
Aber selbst zwischen relativ nahen Regionen gibt es manchmal keine direkte Glasfaserverbindung, sodass die Latenz schlecht ist, etwa bei Routen über Polarregionen.
Ich frage mich, ob es Regionen gibt, die die Dreiecksungleichung deutlich verletzen.
Also Fälle, in denen die Latenz A–C deutlich schlechter ist als die optimale Summe aus A–B + B–C.
Aus Neugier frage ich mich, ob man mit dieser Idee ableiten könnte, welche Rechenzentren wahrscheinlich direkt per Glasfaser verbunden sind, und dann nur diese Verbindungen anzeigen könnte.
Im Grunde sucht man nach Probe-Paaren, bei denen die Roundtrip-Zeit zwischen Probe A und C größer ist als A–B + B–C.
Diese Methode hat die üblichen Probleme von ICMP-/Roundtrip-Zeitmessungen sowie das Problem, dass der Traffic nicht tatsächlich über die „Zwischen“-Probe geroutet wurde, aber solche Paare existieren.
Auf Seite 84 von https://theses.hal.science/tel-03666771/document gibt es ein Beispiel, falls du Französisch lesen kannst.
Wenn der „Umweg“ über B für ICMP-Pakete der günstigste Weg ist, ihr Ziel zu erreichen, wird er wahrscheinlich auch tatsächlich genommen.
Eher könnte man nach Stellen suchen, an denen A–C fast gleich A–B + B–C ist; dort würde man solche Fälle sehen.
Neben fehlender Glasfaser könnten auch finanzielle Gründe wie günstigere Peering-Vereinbarungen eine Rolle spielen.
Soweit ich weiß, ist Mumbai vom südlichen Russland aus geografisch gar nicht so weit entfernt, aber die Latenz ist überraschend hoch.
Zum Beispiel deutlich höher als von Frankfurt nach Moskau; ob das zwischen Frankfurt–Moskau–Mumbai die Dreiecksungleichung verletzt, weiß ich aber nicht.
https://www.submarinecablemap.com/
Weil das Verlegen von Seekabeln extrem teuer ist, ist es sehr unwahrscheinlich, dass es nicht öffentlich bekannte Kabel gibt.
Insgesamt ist dort auch die Paketverlustrate tendenziell höher.
Vor ein paar Tagen habe ich das hier benutzt:
https://aws-latency-test.com/