7
votes

Quelles sont les latences les plus basses possibles pour un moteur de correctif pour envoyer un message correctif du client au serveur?

Je construis un moteur de fixation en C ++ mais je n'ai pas de référence pour savoir ce qui serait considéré comme un bon nombre de performances. Compte tenu de l'heure du réseau et de l'heure d'analyse de la solution, quel serait un bon moment dans les microsecondes pour un client d'envoyer un message correctif à un serveur? Quelqu'un peut également connaître les latences les plus basses possibles actuellement attendues pour ce simple Fix-Message-Message-Message-Message-Server opération?

c++ benchmarking quickfix fix-protocol latency

0 commentaires

4 Réponses :

6
votes

qui dépendra de la rapidité avec laquelle votre moteur de fix peut analyser les octets dans un objet FixMessage et plus important encore sur la vitesse de votre code réseau. Écrivez-vous aussi la pile de réseau? Écrire un moteur de fixation semble simple de l'extérieur, mais il s'agit d'une tâche complexe avec trop de cas d'angle et de fonctionnalités que vous devez couvrir. Allez-vous soutenir la retransmission? Audit asynchrone-journalisation? Fixer les minuteries de session? Des groupes répétitifs à l'intérieur des groupes répétés? Vous devriez envisager d'utiliser un moteur de fixation Open-Source ou commercial.
Quant aux latences à laquelle vous devriez vous attendre, je ne suis pas au courant d'un moteur de fixation pouvant aller sous la forme de 4,5 microsecondes. C'est le temps total à sens unique pour écrire un objet fixMessage à un bytebuffer , transférer le byTEBUNGER sur le réseau sur le serveur, le serveur lit ensuite le byTEBUFFER du réseau et analyse à un FixMessage objet. Si vous utilisez un moteur de fixation de descente, le goulot d'étranglement sera l'E / S réseau, pas l'analyse de la solution.
Pour vous donner quelques chiffres, voici le point de repère pour Coralfix , qui est un moteur de fixation écrit en Java. Si vous pouvez aller en dessous de cela, laissez-moi savoir :) xxx
Disclaimer : Je suis l'un des développeurs de Coralfix.
3 commentaires Je prévois d'utiliser une bibliothèque d'E / S C ++ asynchrone. Comment mesurez-vous le temps sur le côté serveur? Dans mon cas, je contrôle le serveur et le code client afin que je puisse mesurer des deux côtés. Si vous n'avez pas de contrôle sur le serveur, vous ne pouvez mesurer que la rapidité avec laquelle vous pouvez écrire le message sur le réseau. Ensuite, des temps seraient approximativement coupés en deux (~ 2,387 micros). Vous ne pouvez pas utiliser vos points de repère comme sacrosanct. Les messages de test sont très simplistes et ne reflètent pas les messages réels (pas un seul type rejoué de manière cohérente), les gens vont traiter.
0 votes Si vous avez besoin de latences les plus basses, corrigez le client et Fix Server doit être sur le même serveur, même dans la même application à l'aide d'une solution IPC comme perturbateur 0 commentaires 0 votes J'ai assisté à une présentation de la bourse de Singapour il y a quelques années. Ils avaient récemment acheté la plate-forme NASDAQ OMX et revendiquaient les heures de correspondance les plus basses à l'époque, à environ 8 microsecondes si des messages ont été envoyés via le protocole natif. Ils ont ensuite dit qu'ils soutiennent le correctif, ce qui entraînerait 2-3 microsecondes au-dessus du temps de correspondance ... Je suppose que vous pouvez utiliser ce numéro de microseconde 2-3 comme une sorte de tranche de fixation minimale qu'un échange prétendant être le plus rapide géré à réaliser :) 0 commentaires 2 votes Hannibal ante Portas! em>. . . Ne perdez pas le temps d'optimiser dans un mauvais endroit pour les plus faibles chiffres réalisables N'oubliez pas strong> pour vérifier le asic code> strong> / FPGA CODE> STROND> Solutions de protocole de correctif basées sur la base. Toute traitement série séquentielle / simultanée a des moments difficiles à devenir plus rapide qu'une solution de moteur parallèle-silicium. P> On peut atteindre peu de plus profond que d'un 25 ns code> Résolution sur une mesure axée sur le code astopwatch.start (); CallProcessSunderTest (); astopwatch.stop () code> mais les problèmes et problèmes réels sont ailleurs. P> à Avoir une comparaison sur cela, 20 NS CODE> STROND> LATENCE représente environ 5 m de câbles optiques AOC / actifs dans des interconnectes de 120 Gbps dans des clusters de la colocation / des grappes HPC. P > 0: Définir les points de référence: Évitez de comparer les oranges aux pommes h2> Le réglage de la performance et la minimisation de la latence sont des efforts palpitants et remarquables. P> Un premier coup de foudre, demandant au monde "Le plus bas possible tout ce qui est em> strong>" semble attrayant, sinon sexy car il est courant d'entendre dans des médias récents, toutefois toute tentative sérieuse de répondre à ladite forte > "le plus bas possible " em> est difficile sans un soin approprié consacré à un désambigu des problèmes forts> (sinon la démystification (surtout pour éviter les promesses de la Mar / com-générées de recevoir des réponses avant que l'on demande / instantané kharma / éternel Heaven heav al, vous savez assez bien pour mentionner davantage en mentionner) Soins systématiques sur la définition des spécifications afin d'éviter tout malentendu potentiel, moins les interprétations (que ce soit dans la définition des procédures de test de normes ou d'acceptation ou des spécifications d'enveloppes de performance minimales, un produit / service doit se rencontrer de manière à intégrer pleinement opérable). p> si avant de prendre une figure forte>, que ce soit dans [MS], [US] ou [NS], soyez sûr strong> si nous avoir la même configuration de référence d'un système fort> Bystem- u strong> t strong> est soyez double assuré fort> pour qui t WO Points de référence [de] - [à] code> strong> Le chiffre présenté était mesuré. p> 1: Définir le scénario de test (incl. Fix-protocole Message) Fin-to-bout H2> ________________________________________________________________________ +0 [us]-[__BaseLINE__] a decision to send anything is made @ <localhost> | |- <localhost> process wishes to request | a FIX-MarketData | Streaming Updates | for a single item EURCHF | during LON session opening time | |- <localhost> process wishes to request | a FIX-MarketData | Single FullRefresh | for an itemset of: | { EURUSD, GBPUSD, USDJPY, | AUDUSD, USDCAD, USDCHF } | during LON session opening time | + [us]-o======< REFERENCE POINT[A] >=================================== | |- transfer all DATA to a formatting / assembly process-entity | + [us]-o======< REFERENCE POINT[B] >=================================== | |- completed a FIX-message payload to be sent | + [us]-o======< REFERENCE POINT[C] >=================================== | |- completed a FIX-message Header/Trailer/CRC to dispatch | + [us]-o======< REFERENCE POINT[D] >=================================== | |- inlined SSH/DES/AES cryptor communication service processing | + [us]-o======< REFERENCE POINT[E] >=================================== | |- L3/2 transport service protocol SAR / PMD | + [us]-o======< REFERENCE POINT[F] >=================================== | |- L2/1 PHY-device wire-on/off-load process ( NIC / FPGA )-engine | + [us]-o======< REFERENCE POINT[G] >=================================== | |- E2E transport xmit/delivery processing / latency | + [us]-o======< REFERENCE POINT[H] >=================================== | |- L1/2 PHY-device on "receiving"-side wire-on/off-load process | + [us]-o======< REFERENCE POINT[I] >=================================== | |- L2/3 transport recv/handshaking processing / latency | + [us]-o======< REFERENCE POINT[J] >=================================== | |- inlined SSH/DES/AES decryptor processing | + [us]-o======< REFERENCE POINT[K] >=================================== | |- incoming FIX-message Header/Trailer/CRC check-in | + [us]-o======< REFERENCE POINT[L] >=================================== | |- authentication / FIX-Protocol message-counter cross-validation | + [us]-o======< REFERENCE POINT[M] >=================================== | |- FIX-message requested service content de-mapping | + [us]-o======< REFERENCE POINT[N] >=================================== | |- FIX-message requested service execution / handling | + [us]-o======< REFERENCE POINT[O] >=================================== | |- FIX-message requested service response pre-processing / assy | + [us]-o======< REFERENCE POINT[P] >=================================== | [__FinishLINE__] Ready To Send anything back to <localhost> | + [us]-o======< REFERENCE POINT[Q] >=================================== ________|_______________________________________________________________ : SUBTOTAL BEFORE A REQUESTED SERVICE'S RESPONSE-DELIVERY STARTS ________________________________________________________________________ 0 commentaires