L3 IG et la vitesse d'execution des ordres

Hello,

Je viens de faire un double test de vitesse avec 3 connexions réseau différente.

Avec la L3 sur la Profit factor de IG, jou'vre un 1er ticket avec fractionnement (0,5 DAX) et ensuite un ticket sans fractionnement (1 lot DAX).

Connexion 1 : En RDP sur une VM chez AWS situé à Dublin
Connexion 2 : en local chez moi en FTTH
Connexion 3 : via le VPN du bureau (double proxy, tunnel IPSec et tout le toutim).

Testé vers 17h30

Résultats :
Connexion 1 : Entre 0,12 et 0,25 secondes pour chaque tickets.
Connexion 2 : Entre 0,22 et 1,34 secondes.
Connexion 3 : Entre 1 et 4 secondes.

Même avec la plus petite VM la VM d'Amazon et leur accès réseau sont bluffant de rapidité ...

C'est un premier test pour dégrossir. Je recommencerai enter autre sur la Profit factor réel.

En tout cas je suis très agréablement surpris du temps de réaction de la VM (la plus petite en win de chez AWS).
Comme quoi faire du trading avec une session RDP peu être un bon plan même quand on a la fibre chez soi.

J'ai pensé à aire ce test, car je me suis dit AWS me donne un ping d'1 à 3ms secondes avec IG, donc quand je fais du fractionnement ce sera toujours plus rapide que chez mois (entre 9 et 11ms). Effectivement c'est beaucoup beaucoup plus rapide.

J'ai fait un speedstest depuis la VM, j'ai le double en débit par rapport à chez mois et un ping 3x inférieur.

A méditer.

j ai un vps situé a roubaix effectivement le ping entre mon vps et ig est de 3ms mais entre mon pc et le vps j ai 100ms alors que entre mon pc et ig j ai 53ms donc pour moi utilisé la L3 sur vps c est pas un avantage

Oui - tu as tout compris. Le RDP ca permet de se connecter sur le "bureau" du serveur Windows en face. Les concurrent les plus connu : VNC ou encore teamviewer.
L'intérêt de RDP est qu'il est intégré à Windows (server et 7,8,...).

---
- : non je n'ai pas fait cette mesure, c'est ce qui me manque.

---
Oui et non Darth comme tu fais du fractionnement à l'entrée du ticket tu gagnerais énormément à utiliser le programme sur le VPS.

Sinon tu peux le faire ainsi :
Tu ouvres L3 sur la VM chez OVH tu mets le sous-jacent et la quantité voulu
Sur ton ordi local tu ouvres l'interface web et tu trades au ticket.
L3 va te faire le fractionnement aussi vite que l'éclair ...

---
Je savais que ma connexion au bureau était pourri mais à ce point la ...

ok merci Falex j ai compris ou pouvais être l intérêt maintenant, mais je ne fais actuellement plus de fractionnement à l ouverture ...

pout ta connection bureau je crois que c est tout le toutim qui ralentie le plus

même pb que toi swinswing cette semaine encore j était a +0.7 sur DJ je clique et sa clôture à -2.2

Chiffre affiché. Montée au cerveau clicc sur la souris. 1 seconde si tu es en pleine forme concentré

D'ailleurs pour atténuer ce problème, j'envisage de faire un outil logiciel qui cloture automatiquement. mes positions passant bleues fugitivement.
Je n'aurais plus ces délais dus à l'humain et je vais avoir plein de trades qui vont repasser du rouge au bleu.
Le TP à 0 de la L3 règle ce problème mais parfois c'est dommage de ne pas avoir un TP auto dès qu'une pos passe au bleu.

Je pense que c'est exagéré : autant mettre un TP à 0.1 point... En un peu mieux si le tick "saute" les 0.1 pour aller à 0.3 ou 0.7 mais bon, la première perte sera très longue à remonter.

Par contre le même principe pour prendre un TP "à partir de" 1 - 2 - 3 - X points serait intéressant, pour grappiller quelques dixièmes de point.

Le top serait un programme permettant de faire automatiquement ce que fait Benoist avec le temps de latence d'un ordinateur : tant que le tick augmente, laisser courir, au premier tick inférieur, couper.

Sympa les tests!
Ça pourrait être sympa que tu décomposes le temps calculé. Sur mon app j'ai décomposé l'envoi, l'attente de la réponse et le traitement de la réponse, c'est vraiment intéressant à voir.

Cas de fermeture d'un trade:

cpa1.png (5.93 Kio) Vu 1774 fois

On voit bien que le temps de traitement de la réponse est bien supérieur au reste, car il y a des tableaux à actualiser, les stats de l'app à mettre à jour etc etc...
Au final seul le temps d'envoi de la requête et le temps d'attente comptent dans le cas présent, soit 56ms.

En décomposant le temps, il se pourrait que tu soit surpris

Hi Kev,

Sympa ta décomposition.
Effectivement ça pourrait être sympa à ajouter.

Dans la derniere version, j'ai mis le champ "Time" en premier pour que ceux que ça interesse regarde le temps passé.

Comment tu décompose "Sending" et waiting ? Tu te bases sur quoi ?

Comme c'est une webapp en js/jquery, je calcule le sending entre l'évènement mousedown ou mouseup (au choix dans l'app) et "beforeSend" de $.ajax (malheureusement y'a pas d'"afterSend" en jquery) et pour le waiting je calcule entre "beforeSend" et "success".
Dans la réalité, "sending" correspond plutôt au temps de réponse du PC et waiting à l'envoi de la requête ajax + le temps d'attente.

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 1704 fois

Fermeture de trade:

Cap2.png (4.46 Kio) Vu 1705 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.