L3 IG et la vitesse d'execution des ordres

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.