L3 IG et la vitesse d'execution des ordres

Ok mais dans le waiting, tu attends la réponse (OPU ou CONFIRM ou WOU) du flux de streaming, pas d'un polling en REST, je suppose ?

Dans mes mesures c'était :
Du Mouse-dow ---->>> réception de la confirmation en streaming. Donc avec la L3 et une VM windows à dublin chez AWS, ig met entre 12 et 25ms pour ouvrir une position ...

Effectivement je ne calculais pas à la réception de confirmation du flux streaming, j'ai fais la modification, ça ne change pas grand chose au final, même si là, le sending n'a plus vraiment d'intérêt car ça englobe également le temps de réponse REST.

Ouverture de trade:

Cap3.png (4.3 Kio) Vu 947 fois

Fermeture de trade:

Cap2.png (4.46 Kio) Vu 948 fois

Merci j'avais même pas fait attention à ça...

IG met entre 12 et 25ms pour ouvrir une position ...

Ce ne serait pas plutôt 120 et 250 ms ?
0.12s -> 120ms
Ou je me trompe?

Oui tu as raisons.

J'ai mis à jour la L3 pour afficher la vitesse de traitement d'un ticket (OPen, Update, Delete).

Depuis mon bureau c'est une véritable catastrophe : entre 1 et 3 secondes
Depuis un machine à Dublin chez AWS : Open et Delete : Entre 120 et 140ms à l'instant. Les updates sont un poil plus long autour de 500ms.

Cette mesure ne tient pas compte de la durée de "déplacement de mon clique" mais j'ai comme l'impression de le "tunnel RDP" est maintenu en permanence ouvert, donc le proxy de la boite ne perd pas de temps à ouvrir une nouvelle session TCP, et c'est ce qui se passe lorsque je clique avec le programme en "local".

Salut Falex

Je relance ce sujet qui m'intéresse.

Tu écris "une VM windows à dublin chez AWS, ig met entre 12 et 25ms pour ouvrir une position".

Est ce que cela veut dire que ig, grossomodo une fois l'ordre reçu, met entre 12 et 25ms pour l'exécution ? (Sachant que ta VM ping à environ 1ms).

FXCM annonce 16ms en moyenne dans son dernier rapport.

En te remerciant

oulà tu fais de la spéléogie.

Relis mon dernier message juste au dessus, en date du 29/03/2016 : 120 à 140ms depuis AWS.

Attention à ce que l'on mesure.
De mémoire j'affichais le temps entre le clique sur l'interface et le retour de prise en compte ET d’exécution de l'opération.

De mémoire, le temps "réseau" depuis AWS vers l'entrée d'akamai était d'environ 1 à 5ms. ensuite je pense qu'il faut rajouter le même temps pour aller d'akamai jusqu'à ig.
Ensuite il y a les temps de traitement informatique puis la génération des messages de prise en compte et d'exécution.

Tjrs de mémoire, je n'avais aucun moyen de mesurer le temps d’exécution de l'ordre. uniquement la partie visible de l'utilisateur.

Si tu as l'idée de faire du Trading HauteFréquence avec ig, je te dis tout de suite : Laisse tomber. Quand tu envoi des ordres en rafales, tu te prends un message d'erreur, soit au bout du 4./5ième ordre soit si l'intervalle est trop petit (je ne sais pas/plus le critère exact) et tes ordres ne sont pas traités. Recherche dans le forum, il me semble que taka en avait parlé aussi.

Tjrs de mémoire tu dois pouroivr au mieux balancer 4 voir 5 ordres en une secondes.

Maintenant le temps d'execution est pas hyper important puisque la contre-partie sur les cfd à risque limité c'est ig (suaf si tu fais des actions en cfd à risque limité là c'est différents puisque ig va réellement taper dans le CO).
Sur futures, oui c'est une notion importante car si ton brocker fait trainer les ordres sur ses serveurs avant de les transmettre à la place borusière ... le scalping va être plus difficile.

Donc quand FXCM parle de 16ms ... oui mais cela correspond à quelle mesure ???

Merci pour ta réponse.

Ce qui m'intéresse, c'est d'estimer le temps approximatif que met ig à exécuter un ordre au marché (pour une nouvelle position ou pour clôturer une position, dès l'instant où il est reçu chez eux (sous entendu, dès lors qu'il arrive au cœur de leur algo d’exécution, qui doit être une sacrée machine de guerre). Je ne parle pas du temps total A/R, etc...

Bien évidemment je ne suis pas dans une optique HFT au sens : batteries d'ordres, annulation multiples (quote stuffing...) etc... Ce qui m'intéresse, c'est de savoir si ig est en mesure d’exécuter un ordre au marché (de façon ponctuelle et non rapprochée) en un temps max qui me convienne. A cet effet, tu avais indiqué entre 12 et 25 ms, avant de rectifier (je n'avais pas bien lu ton dernier message et celui de Kev au dessus). Ces délais m'inquiètent car ils sont au delà de ma tolérance max en terme de temps d'exe.

Je précise qu'il s'agit d'une config full auto via leur API .NET que j'utilise déjà pour streamer les cours en temps réel et qui fonctionne à merveille.

Je précise aussi que je pars du principe que le temps de transmission à ig sera <1ms (collocation Equinix).

Pour ce qui est de FXCM tout est sur leur site. Ils indiquent à cet effet "Ceci est défini comme le laps de temps qui s'écoule entre le moment où l'ordre est reçu et le moment où il est exécuté. Cela exclut de potentiels retards dus à l'internet et autre booking post-trades."

Si dans les faits FXCM est en mesure de faire du 16ms en moyenne, on doit pouvoir s'attendre à quelque chose de semblable chez ig.

Voilà maintenant dans l'absolu je vais réaliser des tests en démo puis en réel, et je serais alors en mesure d'estimer ce fameux temps moyen d’exécution, en comparant les cours d'exe au cours streamés. Je me demande aussi à cet effet si les cours streamés par ig correspondent bien au flux brut de l'algo ou si c'est un flux qui par moment est tronqué. Ça reste une possibilité, notamment vu les limitations de ce type d'API.

Je me demande aussi à cet effet si les cours streamés par IG correspondent bien au flux brut de l'algo ou si c'est un flux qui par moment est tronqué

Je ne sais pas si ça réponds à ta question mais les ticks reçus par le stream des API ne sont pas complet. J'avais fait un comparatif avec les ticks reçus par PRT qui le montrait. (il n'y avait qu'un faible pourcentage de différence, mais en défaveur de l'API)

Par ailleurs, j'ai dernièrement fait un test sur la durée de passation d'un ordre avec les API.
Sachant que j'ai un ping de 60 ms, je dois attendre 260 ms pour recevoir l'accusé de réception d'IG et 330 ms pour recevoir la confirmation que l'ordre est bien passé. (ce sont des moyennes)

Dans le cas d'un robot, c'est la seconde valeur qui compte car il doit attendre la confirmation finale pour continuer à prendre ses décisions correctement. Si on enlève le ping x 2, cela donne 330 - 120 = 210 ms.

Si on part du principe que l'ordre est toujours confirmé, cela donne un délai de 260 - 120 = 140 ms

Bien vu taka. Si je devais remettre un algo en production je le "hosterai" sur une VM chez AWS ou Azure, là au moins tu es collocalisé avec les edge point d'akamai, tu as un uptime de 99,99 environ et tu peux sizer ta machine en fonction du besoin de calcul.

Avec AWS qui propose du hosting à Londres, je pense que l'on est à l'endroit le plus près d'ig, amis faut tester car j'ai déjà vu des chemin réseau qui pouvait être affreusement long alors qu'en chemoin géographique il était affreusement court.

Exemple un Londre-londres entre deux opérateur internet qui prend presque 30ms ... Comment dire ... bienvenue dans les joies des peering inter-opérateur et de leur politique d'écoulement de trafic.(alors qu'en thorie on doit être dans la 1 voir 2 ms).

Robinhood, n'oublie pas que l'on attaque jamais lees serveurs d'ig en direct mais au travers de tunnles de "collecte" fourni par akamai. Donc se collo à Equinix est certes une bonne idée, mais faut surtout vérifier que le edge akamai par rapport à ton ip est lui aussi collo. C'est le le seul moyen de gagner les quelques ms de transit PCPerso___Akamai.

Merci pour vos retours.

Pour moi le plus important c'est qu'ig puisse m'executer dans les temps les plus cours au marché. La temps de réception de la config est beaucoup moins important dans la mesure où les entrées seront systématiquement accompagnées d'un SL voir SLG et qu'il y aura peu de positions (toutes choses égales par ailleurs).

Il est clair que si ig met disons, plus de + de 100ms à l'exécuter, là où FXCM mettrait 5 fois moins, le choix sera vite fait.

On verra bien à l'usage.