Packets, Transactions and Queues: Design Principles for HFT Systems from a Measurement Study of CME Market Data
Al analizar más de un año de datos del mercado de CME, este artículo desafía el diseño convencional de HFT de un solo hilo al demostrar que, si bien un hilo es suficiente para el procesamiento de paquetes en subperiodos, una arquitectura de hilos de dos etapas puede reducir significamente las colas de espera causadas por ráfagas de transacciones, siempre que la división acorte la etapa más lenta del sistema.
Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo
En el mundo del trading de alta frecuencia, donde las computadoras compran y venden acciones en fracciones de segundo, la velocidad no es solo una ventaja; es el juego entero. Estos sistemas operan bajo una premisa simple: si puedes procesar la información del mercado más rápido que cualquier otro, puedes obtener beneficios de las diminutas diferencias de precios antes de que desaparezcan. Para lograr esto, los ingenieros construyen software especializado que escucha un flujo constante de datos de las bolsas de valores, los decodifica y toma decisiones en microsegundos. Durante años, la industria ha operado bajo una regla estricta: mantener la parte más crítica de este software en un único núcleo de procesador. La lógica era que mover datos entre diferentes núcleos, o "hilos", era demasiado lento y arriesgado, añadiendo retrasos que arruinarían la velocidad del sistema. Este enfoque trataba al software como un trabajador único y concentrado que nunca entrega una tarea, creyendo que cualquier interrupción costaría más que el trabajo mismo.
Sin embargo, esta creencia sostenida durante mucho tiempo dependía de un supuesto sobre cómo llega la información del mercado: que llega como un flujo constante y aleatorio, como gotas de lluvia cayendo a intervalos impredecibles. Si eso fuera cierto, el enfoque de un solo trabajador sería, de hecho, el más rápido. Pero, ¿qué pasa si los datos no caen de forma aleatoria? ¿Qué pasa si llegan en ráfagas repentinas e intensas, donde miles de actualizaciones golpean el sistema en un abrir y cerrar de ojos? Un nuevo estudio de medición de datos reales del mercado de la Chicago Mercantile Exchange sugiere que la vieja regla podría estar equivocada para los momentos de mayor actividad. Al rastrear miles de millones de paquetes de datos durante más de un año, los investigadores descubrieron que los datos del mercado no llegan de forma aleatoria. En su lugar, llegan en grupos compactos, donde un evento desencadena una rápida sucesión de otros, creando un patrón "autoexcitante". Este descubrimiento cambia la matemática de la velocidad. Resulta que, cuando los datos llegan en estas ráfagas específicas y agrupadas, dividir el trabajo entre múltiples procesadores puede, de hecho, hacer que el sistema sea más rápido y fiable, siempre que el sistema esté diseñado para manejar el ritmo de las ráfagas correctamente.
Los investigadores comenzaron analizando el flujo de datos brutos a medida que viajan desde el motor de emparejamiento (matching engine) de la bolsa —donde se procesan las órdenes— hacia las computadoras de los operadores. Siguieron cada uno de los paquetes de datos, anotando exactamente cuándo salían de la bolsa y cuándo llegaban. Descubrieron que el sistema de la bolsa actúa como un guardián con un límite de velocidad fijo. Incluso cuando el motor de emparejamiento procesa órdenes increíblemente rápido —a veces en una fracción de microsegundo una de otra—, el publicador de datos de la bolsa no puede enviarlas todas a la vez. Las envía una por una, con un intervalo mínimo de aproximadamente 7,5 microsegundos entre cada paquete. Esto crea un tren de paquetes de datos que llegan a la computadora del operador con un espaciamiento rítmico y constante, independientemente de lo caótico que fuera la actividad en el origen.
Este arribo rítmico es la clave de los nuevos hallazgos. Los investigadores construyeron una simulación informática para probar cómo diferentes diseños de software manejarían este ritmo específico. Compararon el enfoque tradicional de un solo hilo, donde un procesador hace todo el trabajo, contra un pipeline de múltiples etapas, donde el trabajo se divide entre varios procesadores que trabajan en secuencia. En su simulación, alimentaron el sistema con el cronometraje exacto de los paquetes de datos reales. Los resultados fueron claros: para tareas que toman más tiempo que el intervalo de 7,5 microsegundos entre paquetes, el enfoque de un solo hilo crea un enorme atasco. Cuando llega una ráfaga de datos, el procesador único se ve abrumado, y el retraso para los últimos paquetes de la ráfaga crece hasta ser decenas de veces superior a la tarea misma. Este retraso es la "cola" que los operadores temen, ya que significa que sus decisiones se toman demasiado tarde.
En contraste, el pipeline de múltiples etapas manejó estas ráfagas con facilidad. Al dividir el trabajo, el sistema pudo procesar el tren de paquetes entrantes en paralelo. Mientras el primer procesador estaba decodificando el primer paquete, el segundo ya estaba trabajando en el segundo, y así sucesivamente. Esto permitió al sistema drenar el atasco mucho más rápido, manteniendo el retraso para cada paquete bajo y constante. La simulación mostró que para tareas que toman 16 microsegundos o más, dividir el trabajo reducía los peores casos de retraso en un factor de diez o más, con solo una mínima penalización para los momentos típicos y no ráfagas. Los investigadores confirmaron que esta mejora no se debió al volumen bruto de datos, sino específicamente a la naturaleza agrupada y ráfaga de los tiempos de llegada. Cuando simularon la misma cantidad de datos llegando de forma aleatoria, el sistema de múltiples etapas no ofreció ninguna ventaja, y el sistema de un solo hilo siguió siendo eficiente.
El estudio también descartó otras causas potenciales de los retrasos. Encontraron que el tamaño de los paquetes de datos o el número de mensajes dentro de ellos no era el principal motor de la ralentización. Incluso cuando reorganizaron los datos para eliminar las ráfagas pero mantuvieron el mismo número de paquetes, los enormes retrasos desaparecieron. Esto demostró que el problema era puramente sobre el cronometraje de las llegadas. Los investigadores también analizaron la propia bolsa para entender por qué los datos llegaban en estos grupos. Encontraron que el motor de emparejamiento de la bolsa a menudo procesa múltiples órdenes casi simultáneamente, probablemente porque muchos operadores están reaccionando al mismo evento de mercado al mismo tiempo. Sin embargo, el publicador de la bolsa luego espacia estas órdenes, creando el tren rítmico que los sistemas de los operadores deben manejar.
Para los diseñadores de estos sistemas de trading, el artículo ofrece una guía clara basada en datos. Si el tiempo de procesamiento de un sistema es más corto que el intervalo de 7,5 microsegundos entre paquetes, la vieja regla sigue aplicándose: mantenerlo en un solo hilo. No hay beneficio en dividir el trabajo, y solo añade complejidad innecesaria. Pero si el tiempo de procesamiento es más largo que ese intervalo, el enfoque de un solo hilo fallará durante las ráfagas, y el sistema debe dividirse en múltiples etapas. Los investigadores enfatizan que el objetivo no es usar tantos procesadores como sea posible, sino asegurar que la parte más lenta del proceso sea lo suficientemente rápida como para seguir el ritmo de la bolsa. También encontraron que la disposición específica de los procesadores importa menos que asegurar que la etapa más lenta se gestione de manera eficiente.
Este trabajo no pretende haber resuelto todos los problemas del trading de alta velocidad, ni sugiere que el enfoque de un solo hilo sea obsoleto. Simplemente proporciona una medida precisa de cuándo ese enfoque deja de funcionar y cuándo es necesario un diseño diferente. Al medir el mundo real en lugar de confiar en modelos teóricos, los investigadores han dado a los ingenieros un umbral concreto contra el cual medir. Han demostrado que la naturaleza del flujo de datos —específicamente su tendencia a llegar en ráfagas autoexcitantes— dicta la mejor manera de construir el software que lo consume. La lección es que en el mundo de las altas finanzas, comprender el ritmo de los datos es tan importante como la velocidad de la computadora.
¿Ahogado en artículos de tu campo?
Recibe resúmenes diarios de los artículos más novedosos que coincidan con tus palabras clave de investigación — con resúmenes técnicos, en tu idioma.