Esta pregunta se ha reabierto de nuevo después de haber sido cerrada (con razón) por ser demasiado amplia, con el fin de aclarar algunos conceptos erróneos en relación con una de las respuestas aquí.
La idea principal que hay que destacar aquí es esta: Cuando se trata de operaciones de alta frecuencia, lo más grande o "todo lo que se pueda conseguir" no suele ser cierto.
No sólo es falso, es imposible en términos de requisitos de espacio y otros factores que limitan el aspecto de la arquitectura HFT.
Supongamos que tienes todos los recursos, incluido todo el aspecto monetario de esto. Vamos a repasar algunas de las limitaciones inherentes a lo que son las máquinas HFT coubicadas.
- Tamaño : Independientemente de la cantidad de dinero que tengas que gastar en esto, no tienes el espacio ni siquiera de una pequeña habitación para la máquina HFT de tus sueños. Tienes un bastidor, (o varios bastidores dependiendo del hardware que planees usar y de cuánto dinero tengas).
- CPU : Todos estamos atascados en las mismas CPUs en su mayor parte, y el mismo caso con matrices de puertas programables en campo (FPGAs). Estamos "atascados" en ellos tanto en un sentido de hardware / arquitectura, es decir, ninguna empresa va a estar detrás de la última tecnología de la CPU, y lo que es más importante estamos limitados en un software también tiene sentido. El mismo caso para las GPUs y ASICS también. Es cierto que la limitación del software se debe al hardware, por lo que clasificarla como "limitación del software" puede parecer arbitrario, pero el problema se basa más en la capacidad del software que en la del hardware, dado que esta última está más o menos normalizada en el campo. He aquí un ejemplo que hace que esto sea sencillo de conceptualizar incluso si se sabe nada sobre la programación concurrente multihilo en C++...
Dependiendo de la implementación de hardware específica, vamos a recorrer un escenario investigando la estructura básica de lo que sería.
Para este ejemplo, digamos que puede tener todas las diferentes tareas que se ejecutan en hilos separados (hablando específicamente de HFT aquí) haciendo lo que pueden estar haciendo para la aplicación (por ejemplo, un hilo para hacer frente a los datos de mercado que llegan (un controlador de alimentación), uno para el procesamiento de los datos de mercado, y el hilo de la bolsa / puerta de enlace de órdenes). Vamos a discutir con más detalle lo que estos tres procesos implican para esta configuración de hardware específica.
Nota: En ningún caso estoy diciendo que la siguiente configuración sea el estándar de la industria ni que sea siquiera una inteligente uno. Es sólo un ejemplo que demuestra algo de lo que la estrategia podría estar haciendo con respecto al hardware.
- Manipulador de alimentos: El trabajo de este hilo es tratar los datos de mercado entrantes, y prepararlos para ser enviados al siguiente hilo que tiene más que ver con la estrategia. Este trabajo y la puerta de enlace de la bolsa son a menudo los mayores productores de latencia de la red en general en un sistema HFT. ¿Por qué? Cuando se trata de intercambios y de la red i/o, hay varios factores que plantean desafíos que no pueden predecirse y/o compensarse sobre la marcha. A menudo estos problemas vienen en forma de datos de mercado entrantes que están en incrementos extraños / no consistentes, datos de mercado que no aparecen durante un par de fracciones de segundo, etc.
- Descubrimiento / Generación de señales: El trabajo de este hilo debería ser bastante autoexplicativo, es tomar los datos del mercado y basándose en lo que es la base de la estrategia, tomará alguna decisión basada en lo que está pasando. Algo importante a tener en cuenta aquí es que a menudo esta es la parte que se ve NO en ensamblador/escrito a nivel de hardware dado que los cálculos de esta naturaleza son peligrosos y gravosos para ser iterados a nivel de hardware.
-
Puerta de enlace de Exchange: Una vez más, esto también va a ser uno de los principales contribuyentes de la latencia dada la naturaleza indeterminista del proceso. El trabajo de este hilo es asegurar que cualquier decisión que haya tomado el hilo de generación de señales se transmita de forma precisa y eficiente al intercambio. A menudo, dependiendo de las condiciones del mercado, las órdenes más grandes se dividen en órdenes más pequeñas que se envían a diferentes bolsas/pozos oscuros, dependiendo de cómo se esté comportando el mercado y del tipo de análisis de impacto en el mercado que se haya calculado.
Pero Para que todo esto funcione en este sistema específico tiene que ocurrir algo muy específico, y es lo siguiente: en algún momento durante la ejecución de esta aplicación debe existir alguna forma de "ruta de procesamiento crítica"... donde hay cosas que deben ser tratadas consecutivamente / en algún orden discreto.
Pero, ¿por qué es así? ¿Por qué algunas partes tienen que ser tratadas de forma secuencial? Principalmente, debido al hecho de que, los resultados de lo que cada hilo está haciendo deben ser pasados al siguiente hilo, esto es fácil de visualizar con nuestro ejemplo rudimentario de lo que cada hilo está haciendo en nuestra falsa aplicación HFT.
¿Qué puede haber de malo en esto?
Bueno, para empezar, ¡no necesitas todos estos hilos!
Así que, de esta respuesta :
P: ¿Cuántos procesadores se necesitan y a qué velocidad de reloj? R: todos los que puedas conseguir
no tiene mucho sentido.
Para los aspectos más sensibles a la latencia de un sistema de HFT, va a ver algo que se parece más a esto:
Solo hilos aislados a solo núcleos. ¿Por qué? Hay dos razones principales que se me ocurren: el SO no se interpone en tu camino (es decir, si todo está bloqueado a un núcleo y un hilo, es más fácil tratar con el SO y evitar que delegue otras tareas a ese hilo, lo que te ahorra una preciosa caché). En segundo lugar, cualquier implementación de programación sin bloqueos es mucho más fácil en una configuración como ésta. Para un solo que opera en un solo puede tener llamadas de un solo productor y un solo consumidor que integren lo que ocurre en este núcleo y garanticen su paso eficiente al núcleo de la estrategia que opera de manera similar.
Ahora, a la memoria:
- ¿Cuánta memoria se necesita?
No mucho, en realidad. Definitivamente no " R: lo más imprescindible que se puede conseguir "
Piénsalo así: ¿quieres leer de memoria para hacer HFT?
No, no lo haces y no lo harás. Dada la naturaleza determinista de esta actividad, es imperativo que su ruta de memoria sea rápidamente accesible y no sea susceptible de una pérdida y lectura de la RAM, por lo que mantenerla a bajo nivel en la caché de la CPU es, con mucho, la mejor opción para esto.
¡Ahora, el almacenamiento!
- ¿Cuánto almacenamiento interno necesitas?
De nuevo, algo similar a lo que ocurre con la memoria de acceso aleatorio: leer de la memoria es malo, pero leer de almacenamiento ? Esto sería catastrófico. Los datos de la bolsa se almacenan, pero no in situ. ¿Por qué gastar dinero en un espacio de coubicación y ocuparlo con el almacenamiento de los datos de las garrapatas? La respuesta es que no lo harías.
- ¿Cuántos puertos de red se necesitan?
La otra respuesta cubre esto en su mayor parte, depende de la bolsa y de cómo funcione, sin embargo, en términos generales, no verías más de dos o tres. En teoría, sólo se necesitan conexiones a los gestores de pedidos de la central y éste es otro ejemplo de una limitación inherente; se obtiene el ancho de banda que soporte la central. Esto está relacionado con la última pregunta sobre la fibra y el ancho de banda: dado que se alcanza un límite para el ancho de banda " todos los que puedas conseguir " es una tontería y un sinsentido, como se ha dicho antes. Llegarás a un límite de ancho de banda y más fibra no te aporta absolutamente nada.
El sistema operativo que se ejecuta en las máquinas depende del hardware, y la mayoría de las veces ese aspecto del sistema es menos preocupante. Sólo algo ligero en los recursos que hace que la red del kernel sea más fácil. Si quieres saber de un sistema operativo específico que se utiliza en las máquinas de HFT, sé de una empresa exitosa que utiliza CentOS que es una derivada de la corriente ascendente Red Hat Enterprise Linux (RHEL) . Este último funciona tradicionalmente en servidores x86, x86-64 e Itanium.
Si hubiera que resumir esto en algo extremadamente corto, aquí está:
- Más núcleos de CPU
!= mejor sistema de HFT. Aislar los procesos de clave única a los núcleos tiene más sentido, ya que la comunicación es más fácil (y rápida), y se elimina el pago potencial de lo que el interconexión de rutas rápidas introduce en el sistema.
- la memoria RAM de tu sistema es un factor poco importante dado que la mayoría de las tareas que hacen uso intensivo de la memoria deberían realizarse en la caché de la CPU.
- El almacenamiento es aún menor por una razón similar a la de la RAM: los datos son no almacenado en el sitio y la lectura desde el almacenamiento sería terrible.
- Puertos de red: esto es algo que está más estandarizado que otra cosa, ya que la central está construida de una manera determinada que obliga a todo el mundo a tenerla configurada de una manera determinada.
- Más fibra
!= mayor ancho de banda. El ancho de banda es un factor que también depende en gran medida de la central, más fibra no hará nada por ti.
