Determinar latencias asimétricos en una red
https://stackoverflow.com/questions/1942877
-
20-09-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPregunta
Imagínese que tiene muchos servidores agrupados, a través de muchos ejércitos, en un entorno de red heterogénea, de tal manera que las conexiones entre los servidores pueden tener increíblemente variables latencias y ancho de banda. Usted quiere construir un mapa de las conexiones entre servidores mediante la transferencia de datos entre ellos.
Por supuesto, este mapa puede echarse a perder con el tiempo como los cambios en la topología de la red -. Pero permite ignorar esas complejidades para el presente y asume la red es relativamente estática
Dadas las latencias entre nodos en este gráfico anfitrión, calcular el ancho de banda es un ejercicio simplemente temporización relativa. Estoy teniendo más dificultades con las latencias - sin embargo. Para obtener el tiempo de ida y vuelta, es una simple cuestión de temporización de un ping vuelta y vuelta desde el host local a un host remoto -. Ambos eventos de sincronización (start, stop) se producen en el host local
¿Qué pasa si quiero veces en un solo sentido, bajo el supuesto de que la latencia no es igual en ambas direcciones? Suponiendo que los relojes de los diversos anfitriones no están sincronizados con precisión (al menos que su error es de la misma magnitud que el de las latencias implicadas) - ¿Cómo puedo calcular la latencia de un solo sentido?
En una pregunta relacionada - es esta latencia asimétrica (en el que un enlace es más rápido en la dirección que la otra) común en la práctica? ¿Por qué razones / configuraciones de hardware? Por cierto, estoy al tanto de escenarios de ancho de banda asimétricos, especialmente en la última milla enlaces de consumo tales como DSL y cable, pero no estoy tan seguro de latencia.
Agregado: Después de considerar a continuación el comentario, la segunda parte de la pregunta es probablemente mejor en serverfault .
Solución
A lo mejor de mi conocimiento, las latencias asimétricos - especialmente asimetrías "última milla" - no se puede determinar de forma automática, ya que cualquier protocolo de sincronización de tiempo de red también se ve afectado por la misma asimetría, por lo que no tiene un punto de referencia desde el cual evaluar la asimetría.
Si cada punto final tenía, por ejemplo, su propio reloj GPS, entonces tendría un punto de referencia para trabajar.
medición rápida de parámetros LogP MENSAJE Plataformas Pases , los autores señalan que la medición de latencia requiere sincronización de reloj externa al sistema que se está midiendo. (Negrita énfasis mío, cursiva en texto original.)
latencia asimétrica sólo puede medirse mediante el envío de un mensaje con una marca de tiempo t s , y dejando que el receptor derivar la latencia de t r - t s , donde t r es el tiempo de recepción. Esta requiere sincronización de reloj entre emisor y receptor. Sin sincronización de reloj externa (como el uso de receptores GPS o software especializado como la protocolo de tiempo de red , NTP), los relojes sólo pueden estar sincronizados hasta un granularidad de la ida y vuelta tiempo entre dos anfitriones [10], que es inútil para medir la latencia de red.
No se algoritmo basado en red (como NTP) eliminará los problemas de enlaces de última milla, sin embargo, ya que cada entrada al algoritmo será en sí misma de manera uniforme sujeto a las características de rendimiento del enlace de última milla y por lo tanto no es "externa "en el sentido dado anteriormente. (Estoy seguro de que es posible construir una prueba, pero no tengo tiempo para construir uno en este momento.)
Otros consejos
Hay un proyecto llamado ping unidireccional (OWAMP) específicamente para resolver este problema. La actividad se puede ver en la LKML para añadir marcas de tiempo de alta resolución a los paquetes entrantes (SO_TIMESTAMP, SO_TIMESTAMPNS, etc.) para ayudar en el cálculo de esta estadística.
http://www.internet2.edu/performance/owamp/
Hay incluso una versión de Java:
Tenga en cuenta que timestamping paquete realmente necesita el soporte de hardware y muchos NICs presente generación sólo ofrecen una resolución de milisegundos que puede estar fuera de sincronía con el reloj del ordenador. Hay artículos de MSDN en el DDK sobre la sincronización de acogida y NIC relojes que demuestran problemas potenciales. Las marcas de tiempo en nanosegundos desde el TSC es problemática debido a las diferencias fundamentales y pueden requerir la arquitectura Nehalem para trabajar correctamente en resoluciones requeridas.
http://msdn.microsoft.com /en-us/library/ff552492(v=VS.85).aspx
Se puede medir la latencia asimétrica en el enlace mediante el envío de paquetes de diferentes tamaños para un puerto que devuelve un paquete de tamaño fijo, al igual que enviar algunos paquetes UDP a un puerto que responde con un mensaje de error ICMP. El mensaje de error ICMP es siempre del mismo tamaño, pero se puede ajustar el tamaño del paquete UDP que está enviando.
En ausencia de un reloj sincronizado, la asimetría no se puede medir como probados en la "Fundamental limits on synchronizing clocks over networks". papel 2011
