Packets, Transactions and Queues: Design Principles for HFT Systems from a Measurement Study of CME Market Data
En analysant plus d'un an de données du marché CME, cet article remet en question la conception conventionnelle de HFT à un seul thread en démontrant qu'un seul thread suffit pour le traitement des paquets par sous-période, mais qu'une architecture à deux threads peut réduire considérablement les queues de file d'attente causées par les rafales de transactions, à condition que la séparation raccourcisse l'étape la plus lente du système.
Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète
Dans le monde du trading à haute fréquence, où les ordinateurs achètent et vendent des actions en une fraction de seconde, la vitesse n'est pas seulement un avantage ; c'est tout le jeu. Ces systèmes reposent sur un principe simple : si vous pouvez traiter l'information de marché plus rapidement que quiconque, vous pouvez profiter de minuscules différences de prix avant qu'elles ne disparaissent. Pour ce faire, les ingénieurs construisent des logiciels spécialisés qui écoutent un flux constant de données provenant des bourses, les décodent et prennent des décisions en quelques microsecondes. Pendant des années, l'industrie a opéré selon une règle stricante : garder la partie la plus critique de ce logiciel sur un seul cœur de processeur. La logique était que le transfert de données entre différents cœurs, ou « threads », était trop lent et risqué, ajoutant des délais qui ruineraient la vitesse du système. Cette approche traitait le logiciel comme un travailleur unique et concentré qui ne transmet jamais une tâche, croyant que toute interruption coûterait plus cher que le travail lui-même.
Cependant, cette croyance de longue date reposait sur une hypothèse concernant la manière dont les données de marché arrivent : qu'elles arrivent sous la forme d'un flux régulier et aléatoire, comme des gouttes de pluie tombant à des intervalles imprévisibles. Si cela était vrai, l'approche du travailleur unique serait effectivement la plus rapide. Mais et si les données ne tombaient pas de manière aléatoire ? Et si elles arrivaient par vagues soudaines et intenses, où des milliers de mises à jour frappent le système en un clin d'œil ? Une nouvelle étude de mesure de données de marché réelles du Chicago Mercantile Exchange suggère que l'ancienne règle pourrait être erronée lors des moments les plus denses. En suivant des milliards de paquets de données sur plus d'un an, les chercheurs ont découvert que les données de marché n'arrivent pas de manière aléatoire. Au lieu de cela, elles arrivent en grappes serrées, où un événement déclenche une succession rapide d'autres événements, créant un motif « auto-excitateur ». Cette découverte change l'arithmétique de la vitesse. Il s'avère que lorsque les données arrivent dans ces grappes spécifiques et resserrées, diviser le travail entre plusieurs processeurs peut en fait rendre le système plus rapide et plus fiable, à condition que le système soit conçu pour gérer le rythme de ces rafales.
Les chercheurs ont commencé par observer le flux de données brutes tel qu'il voyage du moteur d'appariement de la bourse (où les ordres sont traités) vers les ordinateurs des traders. Ils ont suivi chaque paquet de données, notant exactement quand il quittait la bourse et quand il arrivait. Ils ont découvert que le système de la bourse agit comme un garde-barrière avec une limite de vitesse fixe. Même lorsque le moteur d'appariement traite les ordres incroyablement vite — parfois à moins d'une fraction de microseconde les uns des autres — l'éditeur de données de la bourse ne peut pas tous les envoyer à la fois. Il les envoie un par un, avec un intervalle minimal d'environ 7,5 microsecondes entre chaque paquet. Cela crée un train de paquets de données qui arrivent à l'ordinateur du trader avec un espacement régulier et rythmé, quelle que soit l'activité chaotique à la source.
Cet arrivage rythmé est la clé des nouvelles découvertes. Les chercheurs ont construit une simulation informatique pour tester comment différents designs de logiciels géreraient ce rythme spécifique. Ils ont comparé l'approche traditionnelle à thread unique, où un seul processeur effectue tout le travail, contre un pipeline à plusieurs étapes, où le travail est réparti entre plusieurs processeurs travaillant en séquence. Dans leur simulation, ils ont injecté le système avec le timing exact des paques de données réelles. Les résultats étaient clairs : pour les tâches qui prennent plus longtemps que l'intervalle de 7,5 microsecondes entre les paquets, l'approche à thread unique crée un énorme arriéré. Lorsqu'une rafale de données arrive, le processeur unique est submergé, et le délai pour les derniers paquets de la rafale devient des dizaines de fois supérieur à la tâche elle-même. Ce délai est la « queue » que les traders redoutent, car cela signifie que leurs décisions sont prises trop tard.
En revanche, le pipeline à plusieurs étapes a géré ces rafales avec aisance. En divisant le travail, le système pouvait traiter le train de paquets entrants en parallèle. Pendant que le premier processeur décodait le premier paquet, le second travaillait déjà sur le deuxième, et ainsi de suite. Cela a permis de vider l'arriéré beaucoup plus rapidement, maintenant le délai pour chaque paquet bas et constant. La simulation a montré que pour des tâches prenant 16 microsecondes ou plus, la division du travail réduisait les délais extrêmes d'un facteur dix ou plus, avec seulement une infime pénalité pour les moments typiques, non chargés. Les chercheurs ont confirmé que cette amélioration n'était pas due au volume pur de données, mais spécifiquement à la nature groupée et par rafales des temps d'arrivée. Lorsqu'ils ont simulé la même quantité de données arrivant de manière aléatoire, le système multi-étapes n'offrait aucun avantage, et le système à thread unique restait efficace.
L'étude a également écarté plusieurs autres causes potentielles de retards. Ils ont découvert que la taille des paquets de données ou le nombre de messages à l'intérieur de ceux-ci n'étaient pas les principaux moteurs du ralentissement. Même lorsqu'ils ont réorganisé les données pour supprimer les rafales tout en conservant le même nombre de paquets, les délais massifs disparaissaient. Cela a prouvé que le problème concernait purement le timing des arrivées. Les chercheurs ont également examiné la bourse elle-même pour comprendre pourquoi les données arrivaient en ces grappes. Ils ont découvert que le moteur d'appariement de la bourse traite souvent plusieurs ordres de manière quasi simultanée, probablement parce que de nombreux traders réagissent au même événement de marché en même temps. Cependant, l'éditeur de la bourse espace ensuite ces ordres, créant le train rythmé que les systèmes des traders doivent gérer.
Pour les concepteurs de ces systèmes de trading, l'article offre un guide précis basé sur les données. Si le temps de traitement d'un système est plus court que l'intervalle de 7,5 microsecondes entre les paquets, l'ancienne règle s'applique toujours : gardez-le sur un seul thread. Il n'y a aucun avantage à diviser le travail, et cela n'ajoute que de la complexité inutile. Mais si le temps de traitement est plus long que cet intervalle, l'approche à thread unique échouera lors des rafales, et le système doit être divisé en plusieurs étapes. Les chercheurs soulignent que l'objectif n'est pas d'utiliser autant de processeurs que possible, mais de s'assurer que la partie la plus lente du processus est assez rapide pour suivre le rythme de la bourse. Ils ont également constaté que l'arrangement spécifique des processeurs importe moins que le fait de s'assurer que l'étape la plus lente est gérée efficacement.
Ce travail ne prétend pas avoir résolu tous les problèmes du trading à haute vitesse, ni suggère que l'approche à thread unique est obsolète. Il fournit simplement une mesure précise du moment où cette approche cesse de fonctionner et où un design différent devient nécessaire. En mesurant le monde réel plutôt qu'en se fiant à des modèles théoriques, les chercheurs ont donné aux ingénieurs un seuil concret sur lequel se mesurer. Ils ont montré que la nature du flux de données — spécifiquement sa tendance à arriver en rafales auto-excitatrices — dicte la meilleure façon de construire le logiciel qui les consomme. La leçon est que, dans le monde de la haute finance, comprendre le rythme des données est tout aussi important que la vitesse de l'ordinateur.
Noyé(e) sous les articles dans votre domaine ?
Recevez des digests quotidiens des articles les plus récents correspondant à vos mots-clés de recherche — avec des résumés techniques, dans votre langue.