Bestimmen Sie asymmetrische Latenzzeiten in einem Netzwerk

Question

Stellen Sie sich vor, Sie haben viele Cluster-Server auf vielen Hosts in einer heterogenen Netzwerkumgebung, so dass die Verbindungen zwischen Servern möglicherweise stark variierende Latenzen und Bandbreite aufweisen. Sie möchten eine Karte der Verbindungen zwischen Servern erstellen, indem Sie Daten zwischen ihnen übertragen.

Natürlich kann diese Karte im Laufe der Zeit veralten, wenn sich die Netztopologie ändert - aber ignorieren Sie diese Komplexitäten für den Moment und nehmen an, dass das Netzwerk relativ statisch ist.

Angesichts der Latenzen zwischen den Knoten in diesem Host-Diagramm ist die Berechnung der Bandbreite ein relativ einfaches Timing. Ich habe jedoch größere Schwierigkeiten mit den Latenzzeiten. Um die Round-Trip-Zeit zu erhalten, ist es eine einfache Sache, ein Rückführungs-Ping von dem lokalen Host zu einem entfernten Host zu takten - beide Timing-Ereignisse (Start, Stopp) treten auf dem lokalen Host auf.

Was ist, wenn ich Einweg-Zeiten unter der Annahme, dass die Latenz ist nicht in beiden Richtungen gleich? Unter der Annahme, dass die Uhren auf den verschiedenen Hosts nicht genau synchronisiert sind (zumindest, dass ihr Fehler von der Größenordnung der Latenzzeiten ist) - wie kann ich die Einweglatenz berechnen?

In einer verwandten Frage - ist diese asymmetrische Latenz (wo eine Verbindung schneller in der Richtung als die andere ist) in der Praxis üblich? Aus welchen Gründen/Hardware-Konfigurationen? Sicherlich sind mir asymmetrische Bandbreiten-Szenarien bekannt, besonders bei Last-Mile Consumer Links wie DSL und Cable, aber ich bin mir nicht so sicher über die Latenz.

Hinzugefügt: Nach der Betrachtung des Kommentars, ist der zweite Teil der Frage wahrscheinlich besser auf serverfault.

Answer 1

Nach meinem Wissen können asymmetrische Latenzen - insbesondere "Last Mile" Asymmetrien - nicht automatisch ermittelt werden, da jedes Netzwerk-Zeitsynchronisationsprotokoll gleichermaßen von der gleichen Asymmetrie beeinflusst wird, so dass Sie keinen Punkt haben Referenz, aus der die Asymmetrie zu bewerten.

Wenn jeder Endpunkt zum Beispiel eine eigene GPS-Uhr hat, dann hätten Sie einen Bezugspunkt, von dem aus gearbeitet werden kann.

In Fast Measurement of LogP Parameters for Message Passing Platforms weisen die Autoren darauf hin, dass die Latenzmessung eine Taktsynchronisation außerhalb des zu messenden Systems erfordert. (Fettdruck emphasis Mine, Kursivschrift in ursprünglichen Text.)

Asymmetric Latenz kann nur durch Senden einer Nachricht mit einem Zeitstempel t _s, und lassen die Empfänger leiten die Latenz von t _{r gemessen werden} - t _s, wobei t _r die Empfangszeit ist. Diese erfordert Uhrensynchronisation zwischen Sender und Empfänger. Ohne externe Uhr Synchronisierung (wie mit GPS-Empfänger oder spezialisierte Software wie Netzwerkzeitprotokoll, NTP), können Uhren nur bis zu einer Granularität der Roundtrip-Zeit zwischen zwei Hosts [10] synchronisiert werden, was nutzlos ist zum Messen der Netzwerklatenz.

Kein netzwerkbasierten Algorithmus (wie NTP) wird die letzte Meile Link Probleme beseitigen, obwohl, da jeder Eingabe für den Algorithmus wird sich auf die Leistungscharakteristik der letzten Meile Verbindung gleichmäßig unterworfen sein und ist daher nicht "extern" in dem oben angegebenen Sinne. (Ich bin zuversichtlich, dass es möglich ist, einen Beweis zu konstruieren, aber ich habe keine Zeit, einen zu konstruieren.)

Answer 2

Sie können asymmetrische Latenz auf Link messen, indem Sie Pakete unterschiedlicher Größe an einen Port senden, der eine feste Größe zurückgibt Paket, wie einige UDP-Pakete an einen Port senden, der mit einer ICMP-Fehlermeldung antwortet. Die icmp-Fehlermeldung hat immer die gleiche Größe, aber Sie können die Größe des von Ihnen gesendeten UDP-Pakets anpassen.

siehe http://www.cs.columbia.edu/techreports/cucs-009-99.pdf

Answer 3

Es ist ein Projekt speziell One-Way Ping (OWAMP) genannt, dieses Problem zu lösen. In der LKML ist eine Aktivität zum Hinzufügen von Zeitstempeln mit hoher Auflösung zu eingehenden Paketen (SO_TIMESTAMP, SO_TIMESTAMPNS usw.) zu sehen, um die Berechnung dieser Statistik zu unterstützen.

http://www.internet2.edu/performance/owamp/

Es gibt sogar eine Java-Version:

http://www.av.it.pt/jowamp/

Beachten Sie, dass Paket timestamping wirklich Hardware-Unterstützung und viele heutige Generation NICs bieten muss nur Millisekundenauflösung, die mit out-of-sync sein kann die Host-Uhr. Es gibt MSDN-Artikel im DDK über das Synchronisieren von Host-& NIC-Uhren, die mögliche Probleme aufzeigen. Zeitstempeln in Nanosekunden vom TSC sind aufgrund von Kernunterschieden problematisch und erfordern möglicherweise, dass die Nehalem-Architektur bei den erforderlichen Auflösungen ordnungsgemäß arbeitet.

http://msdn.microsoft.com/en-us/library/ff552492(v=VS.85).aspx