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 1057 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.