¿Cómo se mide la latencia en entornos de baja latencia?

Question

Aquí está la configuración ... Su sistema está recibiendo un flujo de datos que contiene mensajes discretos (por lo general entre 32-128 bytes por mensaje). Como parte de su canal de procesamiento, cada mensaje pasa a través de dos aplicaciones físicamente separadas que intercambian los datos utilizando un enfoque de baja latencia (como mensajería sobre UDP) o RDMA y finalmente a un cliente a través del mismo mecanismo.

Suponiendo que puede inyectarse en cualquier nivel, incluido el análisis de protocolo de cable, qué herramientas y/o técnicas usaría para medir la latencia de su sistema. Como parte de esto, asumo que cada mensaje que se entrega al sistema da como resultado un mensaje correspondiente (aunque no equivalente) que se envía a través del sistema y se entrega al cliente.

La única herramienta que he visto en el mercado de este tipo es TS-Asociados del inicio del partido. Estoy seguro de que con el derecho de acceso que probablemente se podría medir la misma información utilizando una herramienta de análisis de alambre (Wireshark ALA) y los disectores correctas, pero es este el enfoque correcto o hay alguna solución de las materias primas que puedo usar?

Answer 1

Su último párrafo es la forma típica que hay que hacer. Los sospechosos habituales en este campo (por lo menos por lo que yo sé con datos de mercado (Wall Street) latencia) son:

• TSA (TS Associates)
• Correlix
• Corvil
• Napatech (hardware dispositivos de captura)
• dispositivos Endace (captura de hardware)

había otra empresa mal administrada que recientemente se quemó a través de su dinero VC (4 millones?).

Para los datos que se procesan (digamos en un intercambio directo o RMDS u ​​otro servidor que cambia el protocolo) en diferentes formatos, usted necesita poder analizar las cargas útiles para correlacionar los mensajes. Puede ser un desafío ya que a veces los proveedores de datos no exponen las definiciones de los mensajes.

creo que hay dispositivos de hardware que inyectarán información de carga útil con marcas de tiempo en que lo que el cliente puede ver estos. Por supuesto, como señaló otro afiche, la cuestión del tiempo es muy importante. Todos los dispositivos y clientes deben tener el mismo punto de referencia por tiempo. Tiene que ser preciso ...

La última vez que hablé con TSA, una instalación con 4 puntos de observación era del orden de $ 150k. Sospecho que los otros listados arriba son similares en precio.

Las tarjetas de hardware enumeradas arriba comienzan alrededor de $ 2k (para una tarjeta básica) y aumentan (significativamente) desde allí.

Para hacerlo en software necesitaría tener clientes que usan pcap (o algo similar) y mirar las cargas útiles e intentar hacerlas coincidir. En algunos casos, es difícil hacer que esto sea determinista, especialmente al comienzo de una "sesión" o si faltan mensajes de una tubería. Por lo general, después de un umbral si no coincide con algo, simplemente lo deja caer.

EDIT: RENUNCIA: también soy parte de la empresa y ahora debe revelar este.

Answer 2

El problema de hacer esto es muy similar a medir la "velocidad" en el espacio: ¿tiene que preguntar latencia relativa a qué?Si intenta medirlo en el cable, perderá cualquier latencia adicional en la conmutación, o en la pila de protocolos en el lado de recepción. Realmente no se puede medir de extremo a extremo, ya que las computadoras tendrán dos relojes diferentes que es casi imposible de reconciliar sin introducir pequeños errores (¡y se desvían el uno al otro!)

El único enfoque que realmente tiene alguna esperanza es medir la latencia de ida y vuelta, suponiendo que tiene mensajes que regresan de un extremo acusando recibo. UDP no tiene ACK en la pila, por lo que tendrían que codificarse en la aplicación en alguna parte. Lo que debes hacer es usar algo como elde x86 para medir el tiempo que transcurre entre el envío de un mensaje y la aparición de su respuesta.

Answer 3

A recent paper puede ser de alguna utilidad (y también sería mucho más barato que las soluciones basadas en hardware). También hay formas de explicar con bastante precisión el sesgo del reloj; La última vez que investigué seriamente la investigación de medición de latencia unidireccional (hace un par de años), la técnica más precisa fue linear programming algorithm por Sue Moon (con código de referencia disponible convenientemente here), pero sin utilizar algunas técnicas de programación lineal bastante modernas , es bastante poco práctico hacer como un algoritmo en línea; lo mejor es registrar las marcas de tiempo sin hacer cálculos periódicamente durante el día, y luego ejecutar el algoritmo LP sobre los datos acumulados posteriormente. Hubo algunas otras técnicas que fueron lo suficientemente rápidas como para hacerse en línea (incluido el seminal paper de Vern Paxson), pero todas fueron mucho menos precisas.

Answer 4

Si varios bytes más por mensaje no serán excesivos para ti, te recomendaría simplemente anotar el mensaje en el origen con marca de tiempo completa (64 bits) y en cada salto agregar entrada/dejar marcas deltas horarias (un byte por sello) Al analizar un flujo bidireccional, descubrirá la inclinación del reloj entre cajas y luego podrá tener una información de latencia en tiempo real completa para su consideración o publicación en las herramientas de monitoreo.