Exécution lente des ordres dans une petite société de prop trading : où passe le temps et qui peut y remédier

Une exécution lente est corrigée par celui qui détient la partie du chemin de l'ordre où le temps se perd ; la première tâche consiste donc à trouver cette partie. Horodatez chaque ordre aux points que vous voyez, et le plus grand écart vous dit qui appeler : vos développeurs ou une société d'ingénierie pour les retards dans votre logiciel, un hébergeur pour la distance, le broker pour les retards de son côté.

Que veut dire « notre exécution des ordres est trop lente » ?

Cette plainte peut recouvrir quatre problèmes, et chacun relève d'un responsable différent.

• Tous les ordres sont lents. Le retard est à peu près le même un matin calme et à l'ouverture. Cela désigne un coût que paie chaque ordre, comme la distance, la façon dont vous vous connectez au broker ou un travail lent que votre propre logiciel effectue avant le départ de chaque ordre
• Les ordres sont rapides jusqu'à ce que le marché s'agite. À l'ouverture ou sur une annonce, le retard bondit. Les ordres attendent quelque part dans une file, derrière un programme qui ne suit pas, une limite de messages ou une machine occupée à autre chose
• Les ordres arrivent à temps mais sont exécutés en retard. Un ordre à cours limité reste dans le carnet jusqu'à ce qu'une contrepartie se présente, et sur un marché rapide, le prix s'éloigne. Les horodatages montrent si l'ordre était en retard. Ils ne peuvent pas montrer quel prix était disponible
• L'écran est en retard. Si les prix sur l'écran de trading traînent, les traders cliquent en retard et accusent l'exécution. C'est un problème de données de marché, traité dans un article distinct de ce blog

Seuls les horodatages des ordres réels, et des prix auxquels ils réagissaient, permettent de distinguer ces quatre cas. Servez-vous des plaintes des traders pour choisir les jours à examiner.

Où passent les millisecondes entre notre système et la bourse ?

À l'aller, un ordre traverse quatre tronçons, et l'accusé de réception revient du broker, parfois seulement après que la bourse a accepté l'ordre.

• Votre côté. La stratégie ou le trader décide, l'ordre est construit, vos propres contrôles s'exécutent et l'ordre est envoyé. Les retards viennent du travail fait avant l'envoi, des pauses du programme, des réglages réseau ou d'une machine surchargée. Vos développeurs ou une société d'ingénierie peuvent modifier cette partie
• Le réseau. L'ordre voyage de votre serveur jusqu'au point d'entrée du broker. La distance, le routage internet et les sauts supplémentaires, comme un VPN, ajoutent ici du retard. Un hébergeur ou un fournisseur de colocation, ou un ingénieur réseau, peut le raccourcir
• Le broker. Sa gateway reçoit l'ordre, exécute ses contrôles et l'achemine vers la bourse. Les retards viennent des systèmes propres au broker et de ses contrôles obligatoires. Seul le broker peut les modifier ; vous, vous choisissez comment vous vous connectez et quel broker vous utilisez
• La bourse. Le moteur d'appariement accepte l'ordre et renvoie l'accusé de réception. Peu de temps se perd ici : Nasdaq annonce un aller-retour de l'ordre à l'accusé de réception inférieur à 50 microsecondes sur son réseau de colocation haut débit 10G. Personne que vous puissiez engager ne change cette partie ; vous pouvez seulement vous en rapprocher

Aux États-Unis, les contrôles du broker ne sont pas optionnels. La règle SEC 15c3-5 impose à un broker disposant d'un accès au marché d'« empêcher la saisie d'ordres qui dépassent des seuils de crédit ou de capital appropriés fixés à l'avance » et de rejeter les ordres « qui dépassent des paramètres de prix ou de taille appropriés ». La même règle place ces contrôles « sous le contrôle direct et exclusif du broker ou du dealer ». Vous pouvez demander à un broker combien de temps prennent ses contrôles, mais la règle ne lui permet pas de les désactiver.

Comment savoir où se perd le temps ?

Enregistrez quatre horodatages pour chaque ordre :

• Décision : la stratégie ou le trader a choisi de l'envoyer
• Envoi : l'ordre a quitté votre serveur
• Accusé de réception : la confirmation du broker indiquant qu'il a accepté l'ordre est arrivée sur votre serveur
• Exécution : la confirmation d'exécution est arrivée

Entre la décision et l'envoi, c'est votre logiciel. Entre l'envoi et l'accusé de réception, c'est le réseau et le broker, à l'aller et au retour, plus la bourse si le broker attend sa réponse. Demandez au broker comment il procède. Pour un ordre qui attend dans le carnet, le temps entre l'accusé de réception et l'exécution relève surtout du marché.

Mesurez un chiffre de plus : l'aller-retour réseau entre votre serveur et le point d'entrée du broker. Il vous dit quelle part de l'intervalle entre l'envoi et l'accusé de réception revient au réseau.

FIX est un standard de messagerie pour le trading, maintenu par la FIX Trading Community. Si vous vous connectez en FIX, les messages du broker portent deux horodatages : l'un indique quand le message a été envoyé, l'autre quand s'est produit l'événement qu'il rapporte. La spécification FIX appelle ces champs SendingTime et TransactTime, et le broker peut vous dire quelle horloge renseigne chacun d'eux. Rapprochés de vos propres horodatages, ils montrent quelle partie de l'aller-retour s'est déroulée de quel côté.

Comparer vos horodatages à ceux du broker ne fonctionne que si les deux horloges sont justes. La règle FINRA 6820 impose aux broker-dealers qui déclarent au Consolidated Audit Trail de maintenir leurs horloges métier à moins de 50 millisecondes de l'horloge atomique du NIST. Selon les règles de l'UE, un membre d'une place de marché qui pratique le trading algorithmique à haute fréquence doit maintenir ses horloges à moins de 100 microsecondes de l'UTC. Une horloge autorisée à s'écarter de 50 millisecondes ne permet pas de localiser un retard de quelques millisecondes.

L'envoi et l'accusé de réception sont tous deux horodatés par votre propre horloge : l'intervalle entre eux ne demande donc aucune synchronisation. Commencez par là. Si cet aller-retour est court et que les ordres semblent toujours lents, regardez votre propre logiciel. S'il est long, vérifiez d'abord que votre programme n'était pas en pause ou occupé à l'arrivée de la réponse ; si ce n'était pas le cas, le temps se perd hors de votre logiciel.

Regardez ensuite les ordres les plus lents. Triez une semaine d'ordres par aller-retour et notez le temps que seul un ordre sur cent dépasse ; faites de même pour les premières minutes après l'ouverture et autour des annonces programmées. Une moyenne cache les moments dont les traders se plaignent.

Qu'est-ce qui peut ralentir l'exécution dans une petite prop firm ?

Vérifiez d'abord ces six causes.

• L'API du broker passe par un programme que vous devez faire tourner. Interactive Brokers, par exemple, décrit son API TWS comme reposant sur « la connectivité à Trader Workstation ou à IB Gateway » : chaque ordre passe donc d'abord par l'un de ces programmes. Sa documentation fixe une limite par défaut de « 50 requêtes par seconde » par connexion client et avertit que, dans certains cas, au-delà de ce débit, « certains ordres peuvent être mis en file d'attente et retardés ». Pour ce cas, Interactive Brokers suggère de passer à son API FIX. Si c'est là votre goulot d'étranglement, demandez au broker par quel autre moyen vous pouvez vous connecter
• Le serveur est loin de la destination des ordres. Une machine au bureau ou une région cloud éloignée paie la distance deux fois sur chaque ordre, à l'aller et au retour, et aucune modification du code ne la supprime. Pour la distance la plus courte, Nasdaq offre à ses clients la possibilité de « colocaliser leurs serveurs et leurs équipements dans le data center de Nasdaq ». Avant de payer une colocation, mesurez l'aller-retour réseau entre votre serveur et le point d'entrée du broker
• Un travail lent s'exécute avant l'envoi de l'ordre. Écrire l'ordre dans une base de données, attendre qu'une ligne de log atteigne le disque ou demander à un autre service si l'opération est autorisée ajoute une attente à chaque ordre. Quand la base de données ou le disque est chargé, l'attente s'allonge. Gardez en mémoire ce dont l'ordre a besoin et écrivez les enregistrements une fois l'ordre parti
• Les réglages réseau retiennent les petits messages. Un ordre est un petit message. Le manuel Linux indique que, tant qu'une option de socket appelée TCP_NODELAY n'est pas activée, les données sortantes sont mises en tampon « jusqu'à ce qu'il y en ait une quantité suffisante à envoyer ». Vos développeurs peuvent vérifier si elle est activée
• Le programme se met en pause. Certains garbage collectors arrêtent tout le programme pendant qu'ils nettoient la mémoire. Même le garbage collector de Go, qui fait l'essentiel de son travail pendant que le programme tourne, a de « brèves pauses stop-the-world », et le guide du garbage collector de Go les cite parmi les sources possibles de latence. Si une pause survient pendant qu'un ordre part, l'ordre part en retard. Des graphiques, des backtests ou des rapports qui tournent sur la même machine ont un effet similaire, car l'ordre attend le processeur
• Le chemin propre au broker est lent. Sa gateway, ses contrôles et son routage se trouvent sur le chemin de chaque ordre, et vous ne voyez pas ce qui s'y passe. Vous pouvez demander où se trouve son point d'entrée, quels types de connexion il propose, quelles limites de messages s'appliquent à votre compte, et s'il acceptera de partager ses propres horodatages pour vos ordres

Comment corriger chaque cause, et quelle est l'ampleur du chantier ?

• L'écart entre la décision et l'envoi est grand sur chaque ordre. Sortez le travail lent du chemin de l'ordre et vérifiez les réglages réseau. Il s'agit d'une modification de votre code, parfois d'un seul réglage
• L'écart entre la décision et l'envoi bondit aux moments chargés. Trouvez ce que l'ordre attend : une pause, une file d'attente, une machine partagée. Il s'agit d'une modification du code ou de l'hébergement, ou d'une reconstruction du chemin de l'ordre si la conception elle-même crée une file d'attente
• L'écart entre l'envoi et l'accusé de réception est grand sur chaque ordre. Rapprochez le serveur du point d'entrée du broker, ou changez de type de connexion. Comptez un contrat d'hébergement et un déménagement, ou un travail d'intégration pour une nouvelle connexion
• L'écart entre l'envoi et l'accusé de réception bondit avec le volume. Trouvez la limite que vous atteignez, chez le broker ou dans votre propre connexion. Il suffira peut-être d'une conversation avec le broker, ou de moins de messages de votre côté
• L'écart entre l'accusé de réception et l'exécution est grand. Regardez le type d'ordre et le marché. Ce n'est pas un travail d'ingénierie

Corrigez d'abord la cause confirmée la moins coûteuse et gardez une reconstruction pour la fin. Ne réécrivez pas le système et ne changez pas de broker avant que quelqu'un ait chronométré un ordre, car le retard se trouve peut-être ailleurs.

Qui peut nous aider à corriger une exécution des ordres trop lente ?

Qui peut aider dépend de l'endroit où passe le temps.

• Votre broker. Le seul acteur qui peut voir et modifier son propre côté. Demandez-lui ses horodatages pour vos ordres, ses limites et ses options de connexion
• Un hébergeur ou un fournisseur de colocation, ou l'équipe connectivité de la bourse. Ils louent de l'espace près du point d'entrée du broker ou de la bourse et vendent les lignes réseau qui y mènent
• L'éditeur de votre plateforme de trading, si vous passez par une plateforme sous licence. Seul l'éditeur peut modifier ses rouages internes : apportez-lui donc vos horodatages
• Une société d'ingénierie qui travaille sur les systèmes de trading. Elle mesure tout le chemin, puis modifie ou reconstruit les parties de votre côté, comme le chemin de l'ordre, les contrôles de risque et la connexion au broker
• Vos propres développeurs, si vous en avez. Avec les quatre horodatages, un développeur compétent peut vérifier chaque cause de votre côté du chemin

Qui que vous engagiez, posez d'abord quatre questions :

• Allez-vous mesurer avant de proposer une correction, et qu'allez-vous horodater exactement ?
• Le rapport séparera-t-il notre côté, le réseau et le broker, et montrera-t-il les ordres les plus lents, pas seulement la moyenne ?
• Pour chaque chiffre que vous avancez : à quel percentile, sous quelle charge, à quelle date ?
• Si le retard se révèle être chez le broker, que nous direz-vous ?

Si la réponse à la dernière question reste une reconstruction de votre système, continuez à chercher.

Où se situe amBrain ?

amBrain est une société d'ingénierie logicielle basée à Erevan, en Arménie, qui construit des plateformes de trading à faible latence, des moteurs d'appariement et des systèmes de real-time bidding en Rust. amBrain diagnostique les systèmes lents dans le trading, les paris et l'ad tech : la plateforme en fonctionnement est mesurée de bout en bout, et le rapport indique où passe le temps.

amBrain construit des infrastructures de trading algorithmique : exécution des ordres, données de marché et contrôles de risque pre-trade. Son travail dans le trading comprend le développement de terminaux de trading, les systèmes de gestion des ordres et l'intégration des places de marché via le protocole FIX. amBrain reprend des projets restés bloqués avec une autre équipe et les mène jusqu'en production. Trois formats : livraison complète, équipe dédiée ou ingénieurs intégrés à votre équipe.

Si vous en êtes au début, enregistrez les quatre horodatages un jour normal et un jour chargé. Apportez-les à celui que vous appellerez, amBrain ou quelqu'un d'autre, pour que la première conversation parte de l'endroit où passe le temps.

Questions fréquentes

• Réécrire notre système en Rust rendra-t-il l'exécution plus rapide ? Seulement si le temps se perd dans votre logiciel, et seulement dans la partie que traverse l'ordre. Rust offre des garanties de sécurité mémoire « sans avoir besoin d'un garbage collector », ce qui écarte les pauses du garbage collector comme cause. Cela ne change rien à une machine surchargée, à la distance ou au broker
• Peut-on mesurer sans modifier notre code ? Oui, si votre système journalise déjà les ordres sortants et les confirmations entrantes avec leurs heures : l'aller-retour entre l'envoi et l'accusé de réception se trouve dans ces logs
• Une exécution plus rapide nous donnera-t-elle de meilleurs prix ? Personne ne peut le promettre. La vitesse raccourcit le temps entre une décision et l'arrivée de l'ordre ; le prix obtenu dépend aussi de la liquidité, du type d'ordre et de ce que fait le marché entre-temps