low latency - ¿Qué tan rápido es el estado de los sistemas de negociación HFT hoy en día?
low-latency algorithmic-trading (9)
Todo el tiempo escuchas sobre el trading de alta frecuencia (HFT) y lo rápido que son los algoritmos. Pero me pregunto: ¿qué es lo rápido en estos días?
Actualizar
No estoy pensando en la latencia causada por la distancia física entre un intercambio y el servidor que ejecuta una aplicación comercial, sino la latencia introducida por el programa en sí.
Para ser más específico: ¿Cuál es el tiempo de los eventos que llegan por cable en una aplicación para que la aplicación genere una orden / precio en el cable? Es tiempo de tick-to-trade .
¿Estamos hablando en milisegundos? ¿O sub-microsegundo?
¿Cómo logran las personas estas latencias? Codificando en ensamblaje? FPGAs? ¿Buen código C ++?
Actualizar
Recientemente se ha publicado un interesante artículo sobre ACM, que proporciona muchos detalles sobre la tecnología HFT actual, que es una excelente lectura:
Bárbaros en las puertas de enlace: comercio de alta frecuencia y tecnología de intercambio
"sub-40 microsegundos" si desea mantenerse al día con Nasdaq. Esta figura se publica aquí http://www.nasdaqomx.com/technology/
Cada respuesta aquí tiene al menos cuatro años y pensé que compartiría algo de perspectiva y experiencia de alguien en el campo de negociación HFT / algorítmica en 2018.
(Esto no quiere decir que ninguna de estas respuestas sea deficiente, ya que definitivamente no lo son, sin embargo, creo que es necesario proporcionar información sobre el tema que está más actualizado).
Para responder directamente a la primera pregunta: Estamos hablando de aproximadamente 300 milmillonésimas de segundo (300 nanosegundos) . Recuerde que esta es la latencia introducida por el programa en sí.
Siempre habrá una cierta variedad firma por empresa con respecto a la latencia de los sistemas, sin embargo, los números que voy a proporcionar son los valores comunes para la latencia interna del motor HFT.
- En promedio, un tercio de este tiempo (300 nanosegundos) se atribuye a la latencia introducida por el programa como lo indicó en su pregunta.
- El resto del tiempo es la latencia que existe debido a la ubicación conjunta y otras variables relacionadas con el intercambio, los motores correspondientes, la fibra óptica, etc.
La pregunta es qué tan rápido son los sistemas de comercio de alta frecuencia y cómo se ve la infraestructura en términos del hardware involucrado. La tecnología ha avanzado desde 2014, sin embargo, contrariamente a la gran cantidad de lo que la literatura discute sobre el terreno, los FPGA no son necesariamente la opción preferida de los grandes jugadores en el espacio de HFT . Las grandes empresas como Intel y Nvidia atenderán a estas empresas con su hardware especializado para garantizar que obtengan todo lo que necesitan del sistema de comercio. Con Intel, obviamente, el sistema se construirá más en torno a las CPU y los tipos de cálculos mejor realizados por las CPU, y con Nvidia, el sistema estará más orientado a la GPU.
Para sistemas en arreglos de compuertas programables de campo (FPGA), se usan comúnmente idiomas como Verilog y VHDL. Sin embargo, no todo está en ensamblaje, incluso para sistemas FPGA, la mayor parte es C ++ altamente optimizado con ensamblaje en línea integrado, de ahí viene a menudo la velocidad. Tenga en cuenta que este es el caso de las empresas que utilizan todo tipo de hardware (FPGA, sistemas especializados de Intel, etc.)
Sin embargo, no es feliz que la respuesta principal aquí indique algo completamente falso:
10 nanosegundos y 0.1 nanosegundos son exactamente lo mismo, porque el tiempo que tarda la orden en llegar al servidor de operaciones es mucho más que eso.
Esto es completamente falso ya que el aspecto de co-ubicación del comercio de alta frecuencia se ha estandarizado completamente. Todos están tan cerca del motor de emparejamiento como tú, por lo que la latencia interna del sistema es de gran importancia.
De acuerdo con la página de Wikipedia sobre el comercio de alta frecuencia, el retraso es de microsegundos:
El comercio de alta frecuencia ha tenido lugar al menos desde 1999, después de que la Comisión de Bolsa y Valores de los EE. UU. (SEC) autorizó intercambios electrónicos en 1998. En el cambio de siglo XXI, los intercambios de HFT tenían un tiempo de ejecución de varios segundos, mientras que en 2010 esto había disminuido a mili- y incluso microsegundos.
Has recibido muy buenas respuestas. Sin embargo, hay un problema: la mayoría de algotrading es secreto. Usted simplemente no sabe qué tan rápido es. Esto se aplica en ambos sentidos: es posible que algunos no le digan qué tan rápido funcionan, porque no quieren hacerlo. Otros pueden, digamos "exagerar", por muchas razones (atraer inversionistas o clientes, por ejemplo).
Los rumores sobre los picosegundos, por ejemplo, son bastante escandalosos. 10 nanosegundos y 0.1 nanosegundos son exactamente lo mismo, porque el tiempo que tarda la orden en llegar al servidor de operaciones es mucho más que eso.
Y, lo más importante, aunque no es lo que has preguntado, si intentas comerciar algorítmicamente, no intentes ser más rápido, trata de ser más inteligente. He visto algoritmos muy buenos que pueden manejar segundos completos de latencia y ganar mucho dinero.
Hoy en día, el tick-to-trade de un solo dígito en microsegundos es el estándar para las firmas de HFT competitivas. Debería poder hacer altos dígitos simples usando solo software. Luego <5 usec con hardware adicional.
Por lo que vale, el producto de mensajería FTL de TIBCO es inferior a 500 ns dentro de una máquina (memoria compartida) y unos pocos microsegundos usando RDMA (acceso remoto directo a memoria) dentro de un centro de datos. Después de eso, la física se convierte en la parte principal de la ecuación.
Entonces, esa es la velocidad a la que los datos pueden llegar del feed a la aplicación que toma las decisiones.
Al menos un sistema ha reclamado ~ 30ns de mensajería intertrama, que probablemente sea un punto de referencia ajustado, por lo que cualquiera que esté hablando de números más bajos está usando algún tipo de CPU mágica.
Una vez que está en la aplicación, solo se trata de qué tan rápido el programa puede tomar decisiones.
Soy el CTO de una pequeña empresa que fabrica y vende sistemas HFT basados en FPGA. Construyendo nuestros sistemas en la parte superior de Solarflare Application Onload Engine (AOE), hemos estado entregando consistentemente latencia desde un evento de mercado "interesante" en el cable (datos de mercado de 10Gb / S UDP desde ICE o CME) hasta el primer byte de la mensaje de orden resultante que golpea el cable en el rango de 750 a 800 nanosegundos (sí, sub-microsegundo). Anticipamos que nuestros próximos sistemas de versión estarán en el rango de 704 a 710 nanosegundos. Algunas personas han reclamado un poco menos, pero eso es en un entorno de laboratorio y no estar sentado en un COLO en Chicago y limpiar los pedidos.
Los comentarios sobre física y "velocidad de la luz" son válidos pero no relevantes. Todo el mundo que habla en serio sobre HFT tiene sus servidores en un COLO en la habitación contigua al servidor de la central.
Para entrar en este dominio de sub-microsegundos, no se puede hacer mucho en la CPU host, excepto los comandos de implementación de estrategia de alimentación en la FPGA, incluso con tecnologías como la derivación de kernel tienes 1,5 microsegundos de sobrecarga inevitable ... así que en este dominio todo está jugando con FPGAs.
Una de las otras respuestas es muy honesta al decir que en este mercado altamente reservado, muy pocas personas hablan sobre las herramientas que usan o su desempeño. Cada uno de nuestros clientes requiere que ni siquiera le digamos a nadie que usan nuestras herramientas ni divulgan nada sobre cómo las usan. Esto no solo dificulta el marketing, sino que realmente impide el buen flujo de conocimiento técnico entre pares.
Debido a esta necesidad de entrar en sistemas exóticos para la parte "rápida y malvada" del mercado, descubrirá que los Quants (la gente que presenta los algoritmos que elaboramos van más rápido) están dividiendo sus algos en event-to- capas de tiempo de respuesta. En la parte superior del montón de tecnología están los sistemas de sub-microsegundo (como el nuestro). La siguiente capa son los sistemas C ++ personalizados que hacen un uso intensivo de la derivación del kernel y están en el rango de 3-5 microsegundos. La siguiente capa es la gente que no puede permitirse estar en un cable de 10 Gb / S, solo un salto de enrutador desde el "intercambio", puede que aún estén en COLO pero debido a un juego desagradable que llamamos "ruleta del puerto" están en el docenas a cientos de dominio microsegundo. Una vez que alcanzas milisegundos, ya casi no es HFT.
Aclamaciones
Un buen artículo que describe cuál es el estado de HFT (en 2011) y ofrece algunas muestras de soluciones de hardware que permiten alcanzar nanosegundos: Wall Streets Need For Trading Speed: The Nanosecond Age
Con la carrera por la "latencia" más baja que continúa, algunos participantes del mercado incluso están hablando de picosegundos, trillonésimas de segundo.
EDITAR: Como amablemente mencionó:
El enlace menciona una empresa, Fixnetix, que puede "preparar una operación" en 740ns (es decir, el tiempo desde que se produce un evento de entrada hasta el envío de una orden).
nunca será inferior a unos pocos microsegundos, debido al límite de velocidad w / w luz, y solo unos pocos afortunados, que deben estar a menos de un kilómetro de distancia, incluso pueden soñar con acercarse a eso.
Además, no hay codificación, para lograr esa velocidad debes ir físicamente ... (el chico con el artículo con el interruptor 300ns, ¡eso es solo la latencia añadida de ese interruptor !; igual a 90m de viaje a través de óptica y un poco menos) en cobre)