Quelle est la vitesse actuelle des systèmes de négociation HFT de pointe?
Tout le temps, vous entendez parler du trading haute fréquence (HFT) et de la vitesse à laquelle les algorithmes sont sacrément rapides. Mais je me demande - qu'est-ce qui est rapide de nos jours?
Mise à jour
Je ne pense pas à la latence causée par la distance physique entre un échange et le serveur exécutant une application de trading, mais à la latence introduite par le programme lui-même.
Pour être plus précis: quel est le délai entre les événements arrivant sur le fil dans une application et cette application émet un ordre/prix sur le fil? C'est à dire. tick-to-trade heure.
Parlons-nous de la sous-milliseconde? Ou sous-microseconde?
Comment les gens parviennent-ils à ces latences? Codage en assemblage? FPGA? Bon vieux code C++?
Mise à jour
Un article intéressant sur ACM a récemment été publié, fournissant de nombreux détails sur la technologie HFT d'aujourd'hui, ce qui est une excellente lecture:
Barbares aux portes d'entrée - Technologie d'échange et d'échange à haute fréquence
Vous avez reçu de très bonnes réponses. Il y a cependant un problème - la plupart des échanges de devises sont secrets. Vous ne savez tout simplement pas à quelle vitesse c'est. Cela va dans les deux sens - certains peuvent ne pas vous dire à quelle vitesse ils fonctionnent, car ils ne le veulent pas. D'autres peuvent, disons "exagérer", pour de nombreuses raisons (attirer des investisseurs ou des clients, pour une).
Les rumeurs sur les picosecondes, par exemple, sont plutôt scandaleuses. 10 nanosecondes et 0,1 nanosecondes sont exactement la même chose, car le temps qu'il faut à l'ordre pour atteindre le serveur de trading est bien plus que cela.
Et, plus important encore, bien que ce ne soit pas ce que vous avez demandé, si vous essayez d'échanger par algorithme, n'essayez pas d'être plus rapide, essayez d'être plus intelligent. J'ai vu de très bons algorithmes qui peuvent gérer des secondes entières de latence et faire beaucoup d'argent.
Je suis directeur technique d'une petite entreprise qui fabrique et vend des systèmes HFT basés sur FPGA. En construisant nos systèmes au-dessus du moteur de chargement d'application Solarflare (AOE), nous avons constamment fourni la latence d'un événement de marché "intéressant" sur le câble (flux de données de marché UDP 10 Gb/S d'ICE ou CME) jusqu'au premier octet du message de commande résultant frappant le fil dans la plage de 750 à 800 nanosecondes (oui, sous-microseconde). Nous prévoyons que notre prochaine version des systèmes sera de l'ordre de 704 à 710 nanosecondes. Certaines personnes ont réclamé un peu moins, mais c'est dans un environnement de laboratoire et non pas réellement assis dans un COLO à Chicago et effaçant les commandes.
Les commentaires sur la physique et la "vitesse de la lumière" sont valables mais non pertinents. Tous ceux qui sont sérieux au sujet de HFT ont leurs serveurs dans un COLO dans la pièce à côté du serveur de l'échange.
Pour entrer dans ce domaine inférieur à la microseconde, vous ne pouvez pas faire grand-chose sur le processeur hôte, à l'exception des commandes d'implémentation de la stratégie d'alimentation vers le FPGA, même avec des technologies telles que le contournement du noyau, vous disposez de 1,5 microsecondes de surcharge inévitable ... donc dans ce domaine, tout se joue avec FPGA.
L'une des autres réponses est très honnête en disant que dans ce marché très secret, très peu de gens parlent des outils qu'ils utilisent ou de leurs performances. Chacun de nos clients exige que nous ne disions même à personne qu'ils utilisent nos outils et que nous ne révélions rien sur la façon dont ils les utilisent. Non seulement cela rend le marketing difficile, mais cela empêche vraiment la bonne circulation des connaissances techniques entre pairs.
En raison de ce besoin d'entrer dans des systèmes exotiques pour la partie "rapide et méchante" du marché, vous constaterez que les Quants (les gens qui inventent les algorithmes que nous faisons aller vite) divisent leurs algos en événement à événement. couches de temps de réponse. Les systèmes sub-microsecondes (comme le nôtre) sont au sommet de la technologie. La couche suivante sont les systèmes C++ personnalisés qui font un usage intensif de la dérivation du noyau et ils sont dans la plage de 3 à 5 microsecondes. La couche suivante sont les gens qui ne peuvent pas se permettre d'être sur un câble 10Gb/S à un seul routeur du "échange", ils peuvent être encore chez COLO mais à cause d'un jeu désagréable que nous appelons "roulette de port", ils sont dans le des dizaines à des centaines de domaine microseconde. Une fois en millisecondes, ce n'est presque plus du HFT.
À votre santé
"moins de 40 microsecondes" si vous voulez suivre le Nasdaq. Ce chiffre est publié ici http://www.nasdaqomx.com/technology/
Bon article qui décrit quel est l'état du HFT (en 2011) et donne quelques exemples de solutions matérielles qui rendent les nanosecondes réalisables: Wall Streets Need For Trading Speed: The Nanosecond Age
Alors que la course à la "latence" la plus faible se poursuit, certains acteurs du marché parlent même de picosecondes - des trillionièmes de seconde.
EDIT: Comme Nicholas aimablement mentionné:
Le lien mentionne une entreprise, Fixnetix, qui peut "préparer une transaction" en 740ns (c'est-à-dire que le temps écoulé entre un événement d'entrée et l'envoi d'une commande).
Pour ce que ça vaut, produit de messagerie FTL de TIBCO est inférieur à 500 ns pour une machine (mémoire partagée) et quelques micro secondes en utilisant RDMA (Remote Direct Memory Access) à l'intérieur d'un centre de données. Après cela, la physique devient la partie principale de l'équation.
C'est donc la vitesse à laquelle les données peuvent passer du flux à l'application qui prend les décisions.
Au moins un système a revendiqué une messagerie inter-threads d'environ 30 ns, ce qui est probablement une référence améliorée, donc toute personne parlant de nombres inférieurs utilise une sorte de CPU magique.
Une fois que vous êtes dans l'application, il suffit de savoir à quelle vitesse le programme peut prendre des décisions.
Chaque réponse ici a au moins quatre ans et je pensais partager le point de vue et l'expérience de quelqu'un dans le domaine du trading HFT/algorithmique en 2018.
(Cela ne veut pas dire que ces réponses sont médiocres car elles ne le sont certainement pas, mais je pense qu'il est nécessaire de fournir un aperçu du sujet qui est plus à jour).
Pour répondre directement à la première question: Nous parlons d'environ 300 milliardièmes de seconde (300 nanosecondes) . Rappelons que c'est la latence introduite par le programme lui-même.
Il y aura toujours une certaine variation entreprise par entreprise en ce qui concerne la latence des systèmes, mais les chiffres que je vais fournir sont les valeurs communes pour la latence du moteur HFT interne.
- En moyenne, un tiers de ce temps (300 nanosecondes) est attribué à la latence introduite par le programme comme vous l'avez indiqué dans votre question.
- Le reste du temps est la latence qui existe en raison de la co-localisation et d'autres variables liées à l'échange, aux moteurs correspondants, à la fibre optique, etc.
La question porte sur à quelle vitesse les systèmes de trading haute fréquence sont, et à quoi ressemble l'infrastructure en termes de matériel impliqué. La technologie a progressé depuis 2014, mais contrairement à ce que la littérature discute sur le terrain, Les FPGA ne sont pas nécessairement le choix incontournable pour les grands acteurs de l'espace HFT. Les grandes entreprises telles que Intel et Nvidia répondront à ces entreprises avec leur matériel spécialisé pour s'assurer qu'elles obtiennent tout ce dont elles ont besoin du système commercial. Avec Intel, le système sera évidemment construit davantage autour des processeurs et des types de calculs les mieux effectués par les processeurs, et avec Nvidia, le système sera davantage orienté GPU.
Pour les systèmes sur des matrices de portes programmables sur site (FPGA), des langages tels que Verilog et VHDL sont couramment utilisés. Cependant, tout n'est pas assemblé, même pour les systèmes FPGA, la plupart d'entre eux sont C++ hautement optimisés avec assemblage intégré intégré, c'est de là que vient souvent la vitesse. A noter que c'est le cas pour les entreprises utilisant toutes sortes de matériels (FPGA, systèmes Intel spécialisés, etc.)
Il n'est cependant pas opportun que le réponse la plus élevée ici indique quelque chose de complètement faux:
10 nanosecondes et 0,1 nanosecondes sont exactement la même chose, car le temps nécessaire à l'ordre pour atteindre le serveur de trading est bien plus que cela.
C'est complètement faux car l'aspect de co-implantation du trading haute fréquence est devenu complètement standardisé. Tout le monde est tout aussi proche du moteur d'appariement comme vous l'êtes donc la latence interne du système est d'une grande importance.
De nos jours, le tick-to-trade à un chiffre en microsecondes est la barre pour les entreprises HFT compétitives. Vous devriez pouvoir effectuer des chiffres uniques élevés en utilisant uniquement un logiciel. Puis <5 usec avec du matériel supplémentaire.
Selon la page Wikipedia sur le trading haute fréquence le retard est en microsecondes:
La négociation à haute fréquence a eu lieu au moins depuis 1999, après que la Securities and Exchange Commission (SEC) des États-Unis a autorisé les échanges électroniques en 1998. Au tournant du 21e siècle, les transactions HFT avaient un temps d'exécution de plusieurs secondes, alors qu'en 2010, cette avait diminué en millisecondes et même en microsecondes.
ce ne sera jamais sous quelques microsecondes, en raison de la limite de vitesse em-w/light, et seuls quelques chanceux, qui doivent être à moins d'un kilomètre, peuvent même rêver de se rapprocher de cela.
De plus, il n'y a pas de codage, pour atteindre cette vitesse, vous devez aller physique .. (le gars avec l'article avec le commutateur 300ns; ce n'est que la latence supplémentaire de ce commutateur! en cuivre)