Automated Trading System Architecture

Algorithmic Trading System Architecture Auparavant sur ce blog, j'ai écrit sur l'architecture conceptuelle d'un système de négociation algorithmique intelligent ainsi que les exigences fonctionnelles et non fonctionnelles d'un système de trading algorithmique de production. Depuis, j'ai conçu une architecture de système qui, je crois, pourrait satisfaire ces exigences architecturales. Dans ce post, je vais décrire l'architecture en suivant les directives de la norme ISOIECIEEE 42010 systèmes et la description de l'architecture d'ingénierie logicielle. Selon cette norme, une description d'architecture doit: Contenir plusieurs vues architecturales normalisées (par exemple, UML) et Maintenir la traçabilité entre les décisions de conception et les exigences architecturales Définition de l'architecture logicielle Il n'y a toujours pas de consensus sur ce qu'est une architecture système. Dans le contexte de cet article, il est défini comme l'infrastructure dans laquelle les composants d'application qui satisfont aux exigences fonctionnelles peuvent être spécifiés, déployés et exécutés. Les exigences fonctionnelles sont les fonctions attendues du système et de ses composantes. Les exigences non fonctionnelles sont des mesures permettant de mesurer la qualité du système. Un système qui satisfait pleinement à ses exigences fonctionnelles peut toujours ne pas répondre aux attentes si les exigences non fonctionnelles ne sont pas satisfaites. Pour illustrer ce concept, considérez le scénario suivant: un système de négociation algorithmique que vous venez d'acheter construit fait d'excellentes décisions commerciales, mais il est totalement inopérant avec les systèmes de gestion des risques et de comptabilité des organisations. Ce système répondrait à vos attentes Architecture conceptuelle Une vue conceptuelle décrit les concepts et les mécanismes de haut niveau qui existent dans le système au plus haut niveau de granularité. A ce niveau, le système de négociation algorithmique suit une architecture événementielle (EDA) décomposée en quatre couches, et deux aspects architecturaux. Pour chaque couche et aspect, les architectures et les modèles de référence sont utilisés. Les modèles architecturaux sont des structures génériques prouvées pour répondre à des exigences spécifiques. Les aspects architecturaux sont des préoccupations transversales qui couvrent plusieurs composantes. Architecture événementielle - une architecture qui produit, détecte, consomme et réagit aux événements. Les événements comprennent des mouvements de marché en temps réel, des événements ou des tendances complexes et des événements commerciaux, par ex. Soumettre une commande. Ce diagramme illustre l'architecture conceptuelle du système de négociation algorithmique Architectures de référence Pour utiliser une analogie, une architecture de référence est semblable aux plans pour un mur porteur. Cette impression bleue peut être réutilisée pour plusieurs constructions indépendamment du bâtiment en construction car elle répond à un ensemble d'exigences courantes. De même, une architecture de référence définit un modèle contenant des structures et des mécanismes génériques qui peuvent être utilisés pour construire une architecture logicielle concrète satisfaisant des exigences spécifiques. L'architecture du système de négociation algorithmique utilise une architecture basée sur l'espace (SBA) et un contrôleur de vue modèle (MVC) comme références. On utilise également de bonnes pratiques telles que le stockage des données opérationnelles (ODS), le modèle de transformation et de chargement des extraits (ETL) et un entrepôt de données (DW). Modèle contrôleur de vue - un modèle qui sépare la représentation de l'information de l'interaction des utilisateurs avec elle. Architecture basée sur l'espace - spécifie une infrastructure où les unités de traitement lâchement couplées interagissent les unes avec les autres à travers une mémoire associative partagée appelée espace (illustrée ci-dessous). Vue structurelle La vue structurelle d'une architecture montre les composants et les sous-composantes du système de négociation algorithmique. Il montre également comment ces composants sont déployés sur l'infrastructure physique. Les diagrammes UML utilisés dans cette vue incluent des diagrammes de composants et des diagrammes de déploiement. Vous trouverez ci-dessous la galerie des diagrammes de déploiement du système global de négociation algorithmique et des unités de traitement dans l'architecture de référence SBA, ainsi que des diagrammes de composants associés pour chacune des couches. Tactique architecturale Selon l'institut de génie logiciel, une tactique architecturale est un moyen de satisfaire une exigence de qualité en manipulant un aspect d'un modèle d'attribut de qualité par des décisions de conception architecturale. Un exemple simple utilisé dans l'architecture de système de négociation algorithmique est la manipulation d'un magasin de données opérationnelles (ODS) avec un composant d'interrogation continue. Cette composante analyserait en continu les SAO pour identifier et extraire des événements complexes. Les tactiques suivantes sont utilisées dans l'architecture: Le modèle de disrupteur dans les files d'attente d'événement et d'ordre Mémoire partagée pour les files d'attente d'événements et d'ordre Langue de requête continue (CQL) sur le ODS Filtrage des données avec le modèle de filtre sur les données entrantes Algorithmes d'évitement de congestion sur tous Des connexions entrantes et sortantes Gestion active des files d'attente (AQM) et notification d'encombrement explicite Ressources de calcul des marchandises avec capacité de mise à niveau (évolutive) Redondance active pour tous les points d'échec individuels Indexation et structures de persistance optimisées dans les ODS ODS Historiques des transactions sur toutes les bases de données Checksums pour tous les ordres de détection des fautes Annoter les événements avec des timestamps pour ignorer les événements obsolètes Règles de validation des ordres Quantités commerciales maximales Les composants commerciaux automatisés utilisent une base de données en mémoire pour l'analyse Authentification en deux étapes pour les interfaces utilisateur se connectant aux AT Encryption sur les interfaces utilisateur et les connexions aux ATs Modèle de conception Observer pour MVC pour gérer les vues La liste ci - Décisions que j'ai identifiées lors de la conception de l'architecture. Ce n'est pas une liste complète de tactiques. Au fur et à mesure que le système est en cours d'élaboration, des tactiques additionnelles doivent être employées à plusieurs niveaux de granularité pour répondre aux exigences fonctionnelles et non fonctionnelles. Vous trouverez ci-dessous trois diagrammes décrivant le motif de conception du disrupteur, le modèle de conception du filtre et le composant d'interrogation continue. Vue comportementale Cette vue d'une architecture montre comment les composants et les couches doivent interagir les uns avec les autres. Ceci est utile lors de la création de scénarios pour tester des conceptions d'architecture et pour comprendre le système de bout en bout. Cette vue est constituée de diagrammes de séquence et de diagrammes d'activité. Les diagrammes d'activité montrant le processus interne des systèmes de négociation algorithmique et la façon dont les opérateurs sont censés interagir avec le système de négociation algorithmique sont présentés ci-dessous. Technologies et cadres La dernière étape dans la conception d'une architecture logicielle est d'identifier les technologies et les cadres qui pourraient être utilisés pour réaliser l'architecture. En règle générale, il est préférable de tirer profit des technologies existantes, à condition qu'elles répondent adéquatement aux exigences fonctionnelles et non fonctionnelles. Un cadre est une architecture de référence réalisée, par ex. JBoss est un framework qui réalise l'architecture de référence JEE. Les technologies et les cadres suivants sont intéressants et devraient être pris en compte lors de la mise en œuvre d'un système de négociation algorithmique: CUDA - NVidia a un certain nombre de produits qui soutiennent la modélisation des finances informatiques de haute performance. On peut atteindre jusqu'à 50x améliorations de performance lors de l'exécution de simulations Monte Carlo sur le GPU au lieu du CPU. Apache River - River est un outil-kit utilisé pour développer des systèmes distribués. Il a été utilisé comme un cadre pour la construction d'applications basées sur le modèle SBA Apache Hadoop - dans le cas où l'exploitation forestière omniprésente est une exigence, alors l'utilisation de Hadoop offre une solution intéressante au problème des grandes données. Hadoop peut être déployé dans un environnement clusterisé prenant en charge les technologies CUDA. AlgoTrader - une plateforme de trading algorithmique open source. AlgoTrader pourrait être déployé à la place des composants du trader automatisé. FIX Engine - une application autonome prenant en charge les protocoles FIX (Financial Information Exchange) incluant FIX, FAST et FIXatdl. Bien qu'il ne s'agisse pas d'une technologie ou d'un cadre, les composants doivent être construits avec une interface de programmation d'application (API) pour améliorer l'interopérabilité du système et de ses composants. Conclusion L'architecture proposée a été conçue pour satisfaire aux exigences très génériques identifiées pour les systèmes de négociation algorithmique. D'une manière générale, les systèmes de négociation algorithmique sont compliqués par trois facteurs qui varient selon chaque implémentation: Dépendances des systèmes d'entreprise et d'échange externes Détermination des exigences non fonctionnelles et Évolution des contraintes architecturales L'architecture logicielle proposée devra donc être adaptée au cas par cas Pour satisfaire aux exigences organisationnelles et réglementaires spécifiques, ainsi que pour surmonter les contraintes régionales. L'architecture du système de négociation algorithmique doit être considérée comme un simple point de référence pour les individus et les organisations qui souhaitent concevoir leurs propres systèmes de négociation algorithmique. Pour obtenir une copie complète et les sources utilisées, veuillez télécharger une copie de mon rapport. Merci. Comment une architecture algorithmique de système d'échange ressemble-t-elle Il n'y a réellement que 3 blocs principaux dans un système commercial d'Algo. 3. Le routeur de commande (par exemple le routeur FIX), vous pouvez ajouter des contrôles de risque au module de stratégie ou au module de routeur de commande ou aux deux. Tant que votre flux de données est correct, vous devriez être bon d'aller. Rappelez-vous que vous concevez un ATS pour la latence minimum, et l'ajout de couches ou la complexité viendra au coût de la latence. Une architecture ATS minimale Et si vous ajoutez les cloches et les sifflets, cela ressemblerait à ce qui suit: Si vous êtes également intéressé par la mise en œuvre de l'architecture ci-dessus, vous devriez garder les choses suivantes à l'esprit. Évitez les serrures. Dans le cas où vous devez l'utiliser, essayez de les remplacer par des structures sans serrures en utilisant atomics. Il existe quelques bibliothèques disponibles pour les structures de données sans verrouillage (par exemple libcds, kit de concurrence, etc.). C-11 prend en charge std :: atomic. Et vous devriez vous efforcer de les utiliser aussi. Évitez ce qui est fait dans QuickFIX. Son écrit pour securityflexibilityreusability comme la création et la destruction d'objet (lock) est fait pour chaque invocation de n'importe quel message au routeur. Sûrement pas moyen d'écrire un code de latence sensible. Pas d'allocation de mémoire d'exécution. Runtime doit utiliser la gestion de mémoire personnalisée et sans verrouillage avec pool de mémoire pré-alloué. Toute l'initialisation peut être faite dans les constructeurs. Couplage serré. Le modèle Threading, le modèle IO et la gestion de la mémoire doivent être conçus pour collaborer entre eux pour obtenir les meilleures performances globales. Cela va à l'encontre du concept OOP de couplage lâche, mais son nécessaire pour éviter le coût d'exécution du polymorphisme dynamique. Utilisez des modèles. Dans la même veine, je vous suggère également de regarder C templatization pour atteindre la flexibilité du code. OSHardware optimisation: Enfin, vous devriez chercher à travailler avec Linux RT Kernel et carte de réseau Solarflare avec pilote OpenOnLoad pour atteindre une latence minimale. Vous pouvez en outre chercher à isoler le processeur et exécuter votre programme sur ce noyau particulier. Et enfin, l'API publique que vous devriez exposer aux développeurs de stratégie. Je voudrais que ce soit l'ensemble minimal qui encapsulerait toute la complexité de cette relation d'échange particulière. Classe OrderRouter public: bool virtuel sendNewOrd (OrderInfo) 0 virtuel bool sendRplOrd (OrderInfo) 0 virtuel bool sendCxlOrd (OrderInfo) 0 virtualBut cela signifie que la classe OrderInfo doit avoir TOUS les détails requis par le destinationexchange. En général, les échanges nécessitent le même type d'information, mais comme vous allez le long et de soutenir plus d'échangesdestinations vous vous retrouverez en ajoutant plus de variables dans cette classe. Voici les questions importantes que vous devriez vous poser: 1. Architecture multi-processus ou architecture multi-thread. Qu'il s'agisse de construire un processus monolithique avec plusieurs threads ou d'écrire plusieurs processus. Le coût du processus multiple est la latence du message passant, tandis que le coût pour le processus unique à plusieurs threads est que toute défaillance peut faire tomber le système entier. 2. Passage de message: alors que vous pouvez choisir parmi une pléthore d'options, vous êtes limité par la considération de latence. Le plus rapide IPC serait la mémoire partagée, mais alors comment feriez-vous la synchronisation passer un certain temps avec ces deux questions, car ils seraient le bloc de construction sur lequel votre architecture se tient. Edit: FIX et FAST Concernant le protocole standard, FIX est pour l'envoi d'ordres et FAST est pour les données du marché. Cela dit, la plupart des échanges ont leur propre protocole natif qui est plus rapide que FIX, car FIX est généralement mis en œuvre sur le dessus de leur protocole natif. Mais ils prennent encore en charge FIX ajoute à la vitesse de déploiement. D'autre part, alors que FIX est adopté par la plupart des échanges, FAST ne jouit pas d'une large acceptation. En tout cas, il n'y aurait qu'une poignée d'échanges qui l'adoptent. La plupart d'entre eux envoient plus de FIX lui-même (faible latence), ou utilisent leur propre protocole binaire natif. par exemple. En Inde, NSE, BSE et MCXMCXSX, tous les trois échanges vous donne FIX protocole en plus de protocole natif, mais seulement l'ESB vous donne FAST pour les données du marché. Et c'est aussi passer de FAST à natif avec l'introduction de l'EOBI. Vous pouvez extrapoler la même chose à d'autres échanges. Comme John a mentionné, OMS est le nœud de toute plateforme de négociation et vous devriez commencer à partir de la recherche à ce sujet. Vous devrez passer du temps à déterminer votre cycle de vie commercial, les événements et les fonctionnalités que vous souhaitez intégrer au SGD et ceux que vous souhaitez que votre moteur Algo gère. Metcetera offre un open source OMS, je ne l'ai pas utilisé personnellement mais il est l'un des rares sur le marché. La prochaine chose que vous devriez regarder est de fournir une interface pour les données de source dans et le pousser vers le bas. Ceci est pour un système d'entrée de commande de client pour jeter dans les détails d'ordre et le moteur d'Algo pour le source lui. Beaucoup de Sell Side OMS039s utilisent une combinaison de programmes propriétaires écrits en JavaC en utilisant FIX. Le protocole FIX vous permet de communiquer en temps réel entre les systèmes dans un format de message prédéfini d'amplificateur simplifié établi par la communauté de protocole FIX. Allez à la page d'accueil de l'organisation du protocole FIX gt pour en savoir plus. Examine également le moteur Open Source FIX. Une implémentation open source du moteur FIX. Ensuite vient une interface de données de marché pour la source en temps réel des informations sur le marché de la sécurité, des données allant de HighLowOpenClose à Best BidBest Ask, le volume total négocié, le dernier prix, le dernier volume, offre des citations, demandez des citations etc Les informations que vous recherchez dépend vraiment du type de Stratégie que vous souhaitez mettre en œuvre. Je pense que Interactive Broker fournit un flux de données en temps réel via FIX. La connectivité Exchange est la suivante où votre Algo interprète les signaux, crée un ordre et achemine vers un Exchange ou ECN. Développer en interne pourrait être difficile car vous auriez besoin de travailler sur l'adhésion à l'échange, certifier votre plate-forme et payer une cotisation régulière. Un moyen moins coûteux est d'utiliser une API courtier (comme IB) et de passer l'ordre à travers eux. Les données historiques sont également essentielles, car vous pourriez vouloir comparer le comportement actuel du marché avec ses valeurs historiques. Des paramètres comme l'écart moyen, les profils VWAP, le volume quotidien moyen etc. peuvent être nécessaires pour influencer la prise de décision. Vous pouvez l'avoir sur la base de données (préféré), mais si la vitesse de l'essence, puis le télécharger sur le cache du serveur lorsque vous commencez votre programme. Une fois que vos systèmes périphériques sont configurés, vous pouvez commencer à développer votre programme algo comme vous le souhaitez. Cette infrastructure de base vous permettra de saisir un ordre de produit parent, de lire les données du marché, de réagir aux signaux, mais de générer des ordres enfants et de les placer sur le carnet d'ordres d'échange et les données historiques pour influencer la prise de décision. L'OMS tient le lien entre l'ordre d'enfant parent, ses statuts en temps réel et les mises à jour par l'algo ou la plate-forme de connectivité d'échange. Ce que vous voulez implémenter à l'intérieur de l'Algo, c'est tout à vous. Architecture Algorithmique de Trading Architecture Algorithmique de négociation automatisée ou Trading Algorithmique a été au centre du monde commercial depuis quelques années maintenant. Le pourcentage des volumes attribués à cette forme de négociation a augmenté au cours des dernières années. En conséquence, il est devenu un marché très concurrentiel qui dépend fortement de la technologie. Par conséquent, l'architecture de base a subi des changements majeurs au cours de la dernière décennie et continue de le faire. C'est aujourd'hui une nécessité d'innover sur la technologie afin de rivaliser dans le monde de la négociation algorithmique, ce qui en fait un foyer pour les progrès dans les technologies informatiques et de réseau. Architecture traditionnelle Tout système commercial, conceptuellement, n'est rien de plus qu'un bloc de calcul qui interagit avec l'échange sur deux flux différents. Réception de données de marché Envoie des demandes d'ordre et reçoit des réponses de l'échange. Les données de marché qui sont reçues informent généralement le système du dernier carnet d'ordres. Il pourrait contenir des informations supplémentaires comme le volume échangé à ce jour, le dernier prix négocié et la quantité d'un script. Toutefois, pour prendre une décision sur les données, le commerçant pourrait avoir besoin de regarder les anciennes valeurs ou de dériver certains paramètres de l'histoire. Pour répondre à cela, un système classique aurait une base de données historique pour stocker les données du marché et des outils pour utiliser cette base de données. L'analyse impliquerait également une étude des métiers passés par le commerçant. D'où une autre base de données pour stocker les décisions de négociation ainsi. Dernière, mais pas le moindre, une interface graphique pour le commerçant pour afficher toutes ces informations sur l'écran. Le système entier peut maintenant être décomposé en Le (s) échange (s) le monde externe Le serveur Données de marché reçoivent des données de magasin de magasin Ordres de magasin générés par l'utilisateur Application Prendre des entrées de l'utilisateur y compris les décisions commerciales Interface pour visualiser les informations, Commandes Un gestionnaire de commandes envoie des ordres à l'échange. Nouvelle architecture L'architecture traditionnelle ne pouvait pas s'adapter aux besoins et aux exigences de la négociation automatisée avec DMA. La latence entre l'origine de l'événement et la génération de l'ordre a dépassé la dimension du contrôle humain et est entrée dans le domaine des millisecondes et des microsecondes. Donc, les outils pour gérer les données du marché et de l'analyser nécessaire pour s'adapter en conséquence. La gestion des commandes doit également être plus robuste et capable de gérer beaucoup plus de commandes par seconde. Étant donné que le délai est si petit par rapport au temps de réaction humain, la gestion des risques doit également traiter les commandes en temps réel et de manière entièrement automatisée. Par exemple, même si le temps de réaction d'un ordre est de 1 milliseconde (ce qui est beaucoup par rapport aux latences que nous voyons aujourd'hui), le système est toujours capable de prendre 1000 décisions de négociation en une seule seconde. Cela signifie que chacune de ces 1000 décisions commerciales doit passer par la gestion des risques dans la même seconde pour atteindre l'échange. C'est juste un problème de complexité. Puisque l'architecture implique désormais une logique automatisée, 100 commerçants peuvent maintenant être remplacés par un seul système. Cela ajoute l'échelle au problème. Ainsi, chacune des unités logiques génère 1000 commandes et 100 unités de ce type signifient 100 000 ordres toutes les secondes. Cela signifie que la prise de décision et la partie d'envoi d'ordre doit être beaucoup plus rapide que le récepteur de données de marché afin de correspondre au taux de données. Par conséquent, le niveau d'infrastructure requis par ce module devrait être nettement supérieur à celui d'un système traditionnel (voir la section précédente). Par conséquent, le moteur qui exécute la logique de prise de décision, également connu sous le nom du moteur de traitement des événements complexes, ou CEP, déplacé à partir de l'application vers le serveur. La couche Application, maintenant, est peu plus qu'une interface utilisateur pour visualiser et fournir des paramètres au CEP. Le problème de la mise à l'échelle mène également à une situation intéressante. Disons que 100 logiques différentes sont exécutées sur un événement de données de marché unique (comme discuté dans l'exemple précédent). Cependant, il peut exister des éléments communs de calculs complexes qui doivent être exécutés pour la plupart des 100 unités logiques. Par exemple, le calcul des grecs pour les options. Si chaque logique fonctionnait de manière indépendante, chaque unité ferait le même calcul grec qui utiliserait inutilement les ressources du processeur. Afin d'optimiser la redondance des calculs, les calculs redondants complexes sont habituellement transférés dans un moteur de calcul séparé qui fournit aux Grecs une entrée au CEP. Bien que la couche d'application soit avant tout une vue, certaines des vérifications de risque (qui sont maintenant des opérations nécessitant des ressources en raison du problème de l'échelle) peuvent être déchargées dans la couche d'application, en particulier celles qui ont trait à la santé des entrées des utilisateurs, les erreurs. Le reste des contrôles de risque est effectué maintenant par un système de gestion des risques distinct (RMS) au sein du gestionnaire de commandes (OM), juste avant de libérer une commande. Le problème de l'échelle signifie également que lorsque plus de 100 commerçants différents géraient leurs risques, il n'existe actuellement qu'un seul système RMS pour gérer les risques dans toutes les stratégies des unités logiques. Cependant, certaines vérifications de risque peuvent être particulières à certaines stratégies et certaines pourraient être nécessaires pour toutes les stratégies. Le RMS implique donc le niveau de stratégie RMS (SLRMS) et le RMS global (GRMS). Il pourrait également impliquer une interface utilisateur pour afficher le SLRMS et GRMS. Émergence de protocoles Avec des innovations venues nécessités. Comme la nouvelle architecture était capable de mettre à l'échelle de nombreuses stratégies par serveur, la nécessité de se connecter à plusieurs destinations à partir d'un seul serveur a émergé. Ainsi, le gestionnaire de commandes a hébergé plusieurs adaptateurs pour envoyer des ordres à plusieurs destinations et recevoir des données provenant de plusieurs échanges. Chaque adaptateur agit comme un interpréteur entre le protocole qui est compris par l'échange et le protocole de communication à l'intérieur du système. Les échanges multiples impliquent plusieurs adaptateurs. Cependant, pour ajouter un nouvel échange au système, un nouvel adaptateur doit être conçu et branché dans l'architecture puisque chaque échange suit son seul protocole qui est optimisé pour les fonctionnalités que fournit cet échange. Pour éviter ce problème de l'ajout de l'adaptateur, des protocoles standard ont été conçus. Le plus important parmi eux est le protocole FIX (Financial Information Exchange). Cela non seulement rend gérable de se connecter à des destinations différentes à la volée, mais aussi considérablement réduit à l'aller sur le marché lorsqu'il s'agit de se connecter à une nouvelle destination. La présence de protocoles standard facilite l'intégration avec des fournisseurs tiers, aussi bien pour les analyses que pour les flux de données de marché. En conséquence, le marché devient très efficace comme l'intégration avec un nouveau destinataire destination n'est plus une contrainte. En outre, la simulation devient très facile car la réception de données du marché réel et l'envoi d'ordres à un simulateur est juste une question d'utilisation du protocole FIX pour se connecter à un simulateur. Le simulateur lui-même peut être construit en interne ou acheté auprès d'un fournisseur tiers. De même, les données enregistrées peuvent simplement être rejouées, les adaptateurs étant agnostiques pour savoir si les données sont reçues du marché en direct ou d'un ensemble de données enregistrées. Émergence d'architectures à faible latence Avec les blocs de construction d'un système de négociation algorithmique en place, les stratégies optimisées sur la capacité de traiter des quantités énormes de données en temps réel et de prendre des décisions commerciales rapides. Mais avec l'avènement des protocoles de communication standard comme FIX, la barrière d'entrée de la technologie pour mettre en place un bureau de trading algorithmique, est devenu plus faible et donc plus compétitif. Comme les serveurs ont obtenu plus de mémoire et des fréquences d'horloge plus élevées, l'accent a été déplacé vers la réduction de la latence pour la prise de décision. Au fil du temps, la réduction de la latence est devenue une nécessité pour de nombreuses raisons comme: La stratégie n'a de sens que dans un environnement à faible latence Survie des concurrents les plus aptes vous choisir si vous n'êtes pas assez rapide Le problème est cependant que la latence est vraiment un terme dominant qui englobe plusieurs Différents délais. La quantification de toutes ces variables en un seul terme générique peut ne pas avoir beaucoup de sens. Bien qu'il soit très facile à comprendre, il est assez difficile à quantifier. Il devient donc de plus en plus important de voir comment le problème de la réduction de la latence est abordé. Si nous regardons le cycle de vie de base, Un paquet de données de marché est publié par l'échange Le paquet voyage sur le fil Le paquet arrive sur un routeur du côté du serveur. Le routeur transmet le paquet sur le réseau du côté serveur. Le paquet arrive sur le port Ethernet du serveur. Selon qu'il s'agit d'un traitement UDPTCP et que le paquet dépouillé de ses en-têtes et remorques fait son chemin vers la mémoire de l'adaptateur. L'adaptateur analyse alors le paquet et le convertit en un format interne à la plate-forme de négociation algorithmique. Ce paquet parcourt maintenant les différents modules du système CEP, tick store, etc. Le CEP analyse et envoie une demande d'ordre. L'inverse du cycle comme le paquet de données du marché. Une latence élevée à l'une de ces étapes garantit une latence élevée pour tout le cycle. Par conséquent, l'optimisation de la latence commence habituellement par la première étape de ce cycle qui est de notre contrôle, c'est-à-dire que le paquet se déplace sur le fil. La chose la plus facile à faire ici serait de raccourcir la distance à la destination par autant que possible. Colocations sont des facilités fournies par les échanges pour héberger le serveur commercial à proximité immédiate de l'échange. Le diagramme suivant illustre les gains qui peuvent être réalisés en coupant la distance. Pour tout type d'une stratégie à haute fréquence impliquant une seule destination, Colocation est devenu un defacto doit. Cependant, les stratégies qui impliquent plusieurs destinations nécessitent une planification minutieuse. Plusieurs facteurs comme le temps pris par la destination pour répondre aux demandes d'ordre et sa comparaison avec le temps de ping entre les deux destinations doivent être pris en considération avant de prendre une telle décision. La décision peut également dépendre de la nature de la stratégie. La latence du réseau est généralement la première étape dans la réduction de la latence globale d'un système de négociation algorithmique. Cependant il ya beaucoup d'autres endroits où l'architecture peut être optimisée. Temps de latence de propagation pris pour envoyer les bits le long du fil. Contraint par la vitesse de la lumière bien sûr. Plusieurs optimisations ont été introduites pour réduire la latence de propagation en dehors de la réduction de la distance physique. Par exemple, le temps estimé d'aller-retour pour un câble ordinaire entre Chicago et New York est de 13,1 millisecondes. Spread networks, en Octobre 2012, a annoncé des améliorations de latence. Rapprochement du temps estimé à 12,98 millisecondes. La communication hyperfréquence a été adoptée par des entreprises comme Tradeworx, portant le temps estimé à 8,5 millisecondes. Notez que le minimum théorique est d'environ 7,5 millisecondes. Les innovations continues poussent les frontières de la science et atteignent rapidement la limite théorique de la vitesse de la lumière. Les derniers développements en matière de communication laser, antérieurement adoptés dans les technologies de défense, ont encore rasé une latence déjà mince par nanosecondes sur de courtes distances. La latence de traitement du réseau introduite par les routeurs, les commutateurs, etc. Le prochain niveau d'optimisation dans l'architecture d'un système d'échange algorithmique serait le nombre de sauts qu'un paquet prendrait pour se déplacer du point A au point B. Un saut est défini comme Une partie du chemin entre la source et la destination pendant laquelle un paquet ne passe pas par un dispositif physique comme un routeur ou un commutateur. Par exemple, un paquet pourrait parcourir la même distance par deux chemins différents. Mais il peut avoir deux sauts sur le premier chemin contre 3 sauts sur le second. En supposant que le délai de propagation est le même, les routeurs et les commutateurs introduisent chacun leur propre latence et habituellement sous la forme d'une règle de pouce, plus le saut est plus la latence ajoutée. La latence du traitement du réseau peut également être affectée par ce que nous appelons microbursts. Les micro-rafales sont définies comme une augmentation soudaine du taux de transfert de données qui ne peut pas nécessairement affecter le taux moyen de transfert de données. Puisque les systèmes de négociation algorithmique sont basés sur des règles, tous ces systèmes réagiront au même événement de la même manière. Par conséquent, un grand nombre de systèmes participants peuvent envoyer des ordres conduisant à une soudaine poussée de transfert de données entre les participants et la destination menant à une microburst. Le schéma suivant représente ce qu'est un microburst. La première figure montre une vue de 1 seconde du taux de transfert de données. Nous pouvons voir que le taux moyen est bien en dessous de la bande passante disponible de 1Gbps. Cependant, si vous plongez plus profondément et regardez l'image secondes (la vue de 5 millisecondes), nous voyons que le taux de transfert a dépassé la largeur de bande disponible plusieurs fois chaque seconde. En conséquence, les tampons de paquets sur la pile du réseau, à la fois dans les noeuds finaux du réseau et les routeurs et les commutateurs peuvent déborder. Pour éviter cela, une largeur de bande généralement supérieure à la moyenne observée est généralement attribuée à un système de négociation algorithmique. Temps de latence de sérialisation pris pour tirer les bits sur et hors du fil. Une taille de paquet de 1500 octets transmis sur une ligne T1 (1.544.000 bps) produirait un délai de sérialisation d'environ 8 millisecondes. Cependant, le même paquet de 1500 octets utilisant un modem 56K (57344bps) prendrait 200 millisecondes. Une ligne Ethernet 1G réduirait cette latence à environ 11 microsecondes. Interrompre la latence introduite par les interruptions lors de la réception des paquets sur un serveur. La latence d'interruption est définie comme le temps écoulé entre le moment où une interruption est générée et le moment où la source de l'interruption est traitée. Quand une interruption est générée Les interruptions sont des signaux vers le processeur émis par le matériel ou le logiciel indiquant qu'un événement nécessite une attention immédiate. Le processeur à son tour répond en suspendant son activité en cours, en sauvegardant son état et en gérant l'interruption. Chaque fois qu'un paquet est reçu sur la carte réseau, une interruption est envoyée pour traiter les bits qui ont été chargés dans la mémoire tampon de réception de la carte réseau. Le temps nécessaire pour répondre à cette interruption affecte non seulement le traitement de la charge utile nouvellement arrivée, mais également la latence des processus existants sur le processeur. Solarflare a introduit open onload en 2011, qui implémente une technique connue sous le nom de kernel bypass, où le traitement du paquet n'est pas laissé au noyau du système d'exploitation, mais à l'espace utilisateur lui-même. Le paquet entier est directement mappé dans l'espace utilisateur par le NIC et y est traité. En conséquence, les interruptions sont complètement évitées. En conséquence, le taux de traitement de chaque paquet est accéléré. Le schéma suivant illustre clairement les avantages de la dérivation du noyau. Temps de latence d'application pris par l'application à traiter. Cela dépend des différents paquets, du traitement alloué à la logique d'application, de la complexité du calcul impliqué, de l'efficacité de la programmation, etc. L'augmentation du nombre de processeurs sur le système réduirait en général la latence de l'application. Same is the case with increased clock frequency. A lot of algorithmic trading systems take advantage of dedicating processor cores to essential elements of the application like the strategy logic for eg. This avoids the latency introduced by the process switching between cores. Similarly, if the programming of the strategy has been done keep in mind the cache sizes and locality of memory access, then there would be a lot of memory cache hits resulting further reduction of latency. To facilitate this, a lot of system use very low level programming languages to optimize the code to the specific architecture of the processors. Some firms have even gone to the extent of burning complex calculations onto hardware using Fully Programmable Gate Arrays (FPGA). With increasing complexity comes increasing cost and the following diagram aptly illustrates this. Levels of sophistication The world of high frequency algorithmic trading has entered an era of intense competition. With each participant adopting new methods of ousting the competition, technology has progressed by leaps and bounds. Modern day algorithmic trading architectures are quite complex compared to their early stage counterparts. Accordingly, advanced systems are more expensive to build both in terms of time and money.