L3 IG et la vitesse d'execution des ordres

Effectivement, de mon coté, je n'ai fait que mesurer (sommairement) les délais des dialogues entre mon programme et ig.
Je n'ai pas essayé de mesurer le temps exact que mettait ig à passer réellement l'ordre.
C'est pourtant une donnée intéressante et je vais implanter dès que possible un système pour la mesurer.

Tu vas mesurer comment ?
On a juste le timing d’émission, au pire tu déduis le temps de transport sur le réseau de l’aller et du retour mais encore celui-ci n’est pas complet puisque on ne peut mesurer que le segment pc-akamai
Le segment Akamai-ig peut juste être évaluer en ordre de grandeur pas en valeur exact.

Pourquoi est-ce important ? Tu peux développer Robin Hood ?

En colloc sur Equinix LD4 ig ce sera à 1ms ou moins. Disons qu'en dessous de 5ms, le temps de trajet n'est pas un sujet. Le sujet c'est le temps de traitement d'un ordre lambda. Bien évidement on peut supposer que suivant la taille de l'ordre, les conditions de marché, l'état de l'offre et de la demande,etc..., le temps d'exe ne soit pas le même. C'est tout à fait "normal".

C'est important pour des raisons qui me sont propres.

Une des pistes pour mesurer, c'est de comparer les prix d’exécution aux cours streamés (tu pensais à autre chose Taka ?). D'où mon échange avec Taka sur le sujet sur la complétude des ticks diffusés par ig via leurs API non FIX. A cet effet j'ai une question : savez vous si il y a possibilité d'avoir un timestamp en ms sur les exécutions ? Dans les rapports d'ig c'est uniquement à la SEC. N'ayant pas encore testé les objets de trading de leur API je me pose la question.

PS : autre piste pour le temps moyen d'exe => leur demander. Si FXCM diffuse cette donnée, pourquoi ig ne le ferait pas ?

Sur Eurex CME etc tu le sais. Quand la place boursière a reçu ton ordre. Tout est horodaté (confirmation de réception horodaté, placement dans le CO horodaté, exécution horodaté...) Et quand elle le met dans le carnet d’ordres. Cela va de 20 à 180 ms entre la réception et le placement dans le carnet d’ordre. Chaque ordre a un temps très différent. Jamais le même

@Benoist : où puis-je trouver les infos dont tu parles sur l'horodatage ? La seule donnée horodatée c'est le champs "Date/Heure de transaction" (Trade Date/Time dans les rapports), qui d'ailleurs est au format SEC et pas ms. J'ai fouillé sur l’interface de gestion du compte, je n'ai pas trouvé. Merci par avance,

Il faut être sur futures options ou actions chez ib. prorealtime les donne avec le petit point d’interrogation pour chaque trade. C’est une donnée transmises par les places boursières. Peut-être pas toutes mais là où je trade je les ai. CME Eurex nasdaq

Je t'ai posé la question car je suis justement client Futures chez ib

Sur le relevé d’ordres prorealtime il y a un petit icône et tu as tout à la ms

J'ai trouvé c'est bon. Rapports => Relevés => Téléchargement de prestataires tiers. Ca sort des fichiers de log. Ca ressemble au FIX.

Robinhood je répéte : certes être à Equinix LD4 te rapprochera d'Akamai (et encore c'est à vérifier) mais est-ce que tu seras plus près d'ig ? à voir.
Après tu peux supposer que les serveurs d'ig sont hostés chez WS ou Equinix ou Level3 (enfin peut importe le hosting center) à Londres, donc il n'y a , en théorie, plus que le temps de transit Paris-> londres (soit 10ms et moins de mémoire).

https://www.peeringdb.com/net/2 : Akamai a un point de peering à LD4. Maintenant faudrait voir si ça "route" par là.

Tu les as en mode graphique aussi. Dans ta liste des ordres exécutés rajoute l’option

Dans les rapports d'IG c'est uniquement à la sec.

Effectivement. J'avais pensé pouvoir retrouver une heure à la milliseconde mais, sauf erreur, il n'y en a ni dans les OPU, ni dans les CONFIRM ni dans l'HISTO.

@Taka : oui nulle part. D'ailleurs quand j'avais analysé les spreads réellement payés, j'avais été contraint de prendre le cours moyen au cœur de la seconde exécution. Pas terrible. Après comme tu la évoqué, on peut réduire l'intervalle en prenant en compte le timestamp de notre côté en ms, le timestamp ig en SEC, et le timestamp de confirm de l'ordre reçu de notre côté en ms. Je ne vois pas comment on pourrait être plus précis..?

- Falex : je verrais bien avec le vps equinix. Depuis Paris je suis à 10ms. Ça ne pourra être que meilleur. C'est pas le sujet central. Mais merci davoir mis en avant cette histoire de routine via Akamai

@Benoist : ok je vais regarder merci

ARf dans les stream les tick sont avec un timestamp en ms (base epoch)

Mais dans la doc (https://labs.ig.com/streaming-api-reference), ils ne précisent pas le format du timestamp des OPU et WOU.
Mais comme taka, j'ai plus souvenir d'un HH:MM:SS que d'un temps de type epoc en ms.

---

Je reviens à la question de base : Tu peux développer pourquoi le temps d'exec et si important, j'ai pas compris ta première réponse ?

Il est important pour moi 1 de connaitre le temps moyen d’exécution et 2, de m'assurer que les delais d'exe sont homogènes (faible écart type) pour des ordres au marché (identiques donc).

Ok ça j’ai compris mais si tu développe en quoi cela va être utile ?

Ça m'est utile pour qu'ensuite je puisse comparer mes cours d’exécution au cours streamés et voir dans quelle mesure l’exécution est fidèle ou non.

Salut à tous !

Excellente année 2020++

@Falex : "jou'vre un 1er ticket avec fractionnement (0,5 DAX) et ensuite un ticket sans fractionnement (1 lot DAX)."

A tout hsard, aurais tu observé en moyenne un délai moyen d’exécution plus fort pour les ordres fractionnés ?

Je reviens sur le sujet rapidement.

Après avoir réalisé pas mal de tests sur différents pc et vps, ma conclusion est la suivante : pour l'API REST, le temps de traitement d'un ordre est hautement dépendant de la capacité de la machine a envoyer une requête POST via le client http.

Je m'en suis aperçu en comparant notamment des mesures de temps de ma machine vs des vps collés à ig. Et là grosse surprise en remarquant que les délais étaient en premier lieux hautement corrélés à la vitesse du cpu et loin derrière, à la proximité avec le serveur hébergeant le moteur d'exe d'ig.

Je suis désormais à la recherche de solutions pour rendre plus rapide la requête "client.PostAsync(_baseUrl + uri,scontent).Result". Voilà ce que j'ai testé :

- Garder ouvert le client "httpClient"
- Tester des options diverses pour forcer le maintien de la connection entre une première opération et d'autres ultérieures (cf "keep alive", "connection.close", etc...)

Rien n'y fait. Je tombe sur un délai qui parait incompressible.

Connaissez vous des alternatives qui permettraient de rendre plus rapides les requêtes REST ? Je pense notamment à Taka qui est expert en .Net et doit forcément bien connaitre ce type de problématiques

En dernier recours j'ai l'option FIX mais c'est lourd à implémenter donc je garde en plan B.

PS : il y a bien une possibilité de récupérer une date via "confirms" avec la précision ms pour info.

Je commence effectivement à bien connaître dot.net mais pas asp.net c’est à dire les interactions avec le web
Pour le moment je me suis contenté d’implémenter simplement les requêtes REST sans chercher à les optimiser. Je n’ai d’ailleurs aucune idée de la manière de s’y prendre. Je suis tes recherches avec intérêt mais, je le regrette, je ne peux pas y apporter grand chose.