TakaPeek3 2019 : récupération de l'historique des ticks IG

,

De nouveau API ou pas les ordres sont exécutés de la même manière. L'avantage côté client c'est bien sûr la capacité à pouvoir envoyer un ordre plus rapidement qu'en passant par la plateforme web ou un intermédiaire type prt.

Via lightstreamer les ordres market sont exécutés entre 60ms et 200ms dans 99.9999% des cas. Via l'API FIX c'est beaucoup plus rapide mais cette API est réservée aux gros comptes. Pour info leur booking engine est à Londres, dans leur HQ.

Ensuite sur l'algo d’exécution tu en as au minimum 2. Un qui exécute immédiatement l'ordre du client et qui le hedge éventuellement ex-post. Market making pur. Un autre qui exécute en mode intermédiaire. Ton ordre est routé directement à une table de Si tu ne l'as pas déjà fait, il faut que tu retournes dans ta présentation afin de lire le lien important qu'on t'a donné. (liquidity provider) = ce que fait FXCM par exemple.

La décision de routage ou non dépend de la façon dont ils ont modélisé ton profil, de leurs capacité à hedger en interne à l'instant t (= état de leur book) et notamment du marché sous-jacent. Par du principe que plus tu es gagnant et plus tu es gros et plus ton ordre aura de chances d'être routé = ig ne sera pas ta Contrepartie directe. Dans l'absolu pas de diff en termes de coûts de transaction. En revanche l’exécution est un peu plus longue et les ordres peuvent être rejeté plus facilement.

Je rappelle ici que l'essentiel du CA obtenu par ig est fait sur le dos des clients gagnants et pas des perdants. Les perdants sont en revanche assez utiles pour les compensations internes, surtout dans la mesure où ils pissent en général contre le vent.

PS : tout histoire d'extra latence par ig, de 10 SEC etc.. c'est du pur fantasme.

"Et puis, mon nom est vraiment - "
Désolé, je retire ce que j'ai écrit !

,
"de Si tu ne l'as pas déjà fait, il faut que tu retournes dans ta présentation afin de lire le lien important qu'on t'a donné"

Je n'ai jamais écris ça. C'est une séquence de mots typique d'andlil qui est automatique et qui a du être déclenchée à la suite de mots que j'ai moi même écrit.

Le message original devait être :

"Ensuite sur l'algo d’exécution tu en as au minimum 2. Un qui exécute immédiatement l'ordre du client et qui le hedge éventuellement ex-post. Market making pur. Un autre qui exécute en mode intermédiaire. Ton ordre est routé directement à un inter_médiaire (liquidity provider) = ce que fait FXCM par exemple."

J'ai trouvé du temps pour répondre à tes autres questions :

Apparement, ce que tu as fait est en C# dot net et tourne sur une dedibox ?
J’ai écrit différents programmes, un en Delphi et tous les autres en C#
Seuls TakaPeek3 qui récupère l’historique des ticks fonctionne sur un serveur séparé, 24h/24H (VPS Contabo)

C'est open source ou pas ?
Non, ce n’est pas Open Source car tout mon éco-système de développement est étroitement lié, et je veux conserver certains développements pour moi.
C’était, au départ, des outils purement personnels qui n’avaient pas été écrits pour être partagés, ce qui est arrivé plus tard.
Il y a un github ?
Non, c’est inutile dans mon cas car je suis le seul à intervenir.

Avec TakaSynchroniser ?
TakaSynchroniser est un programme à part qui sert juste à synchroniser mes sauvegardes d’une machine à l’autre sur mon réseau local.

Tu as un FTP où on peut télécharger les historiques automatiquement où tu les partages à la demande sur google drive ?
J’avais installé un FTP sur le VPS Contabo et c’est justement lui qui a permis le piratage du serveur. Je l’ai supprimé depuis.
Les données récupérées sont écrites dans un répertoire Dropbox qui les synchronise automatiquement dans le cloud (voir le lien donné par Robinhood pour leur récupération). Après plusieurs tests, il s'avère que Dropbox est plus performant que les autres solutions pour faire cela.

"Je répète encore : parce que ce ne sont pas les mêmes types d'ordres (ordre limite et ordre au marché) et il n'y a rien à faire (pour la question suivante lol) les ordres envoyées par les api ne bénéficient pas des améliorations de cours."
Cette phrase de Benoist est parfaitement exacte. Mais il ne parle pas de tous les programmes utilisant les Api IG. Il parle seulement de TakaScalper, un ancien programme de scalping que j’avais écrit et qui ne passait que des ordres au marché.

Est-ce que tu as aussi des pertes de ticks (à cause du lightstreamer) ? Comment tu gère ça ?
Comment tu intercepte le message d'erreur takapoto ?
Tu veux dire que tu reçois un message d'ig quand le flux se met à partir en vrille ?
Si tu veux que je précise ma première réponse, dis-le moi

=> piratage ! Et en plus tu as la clef de ton Api IG dans le logiciel !
Toutes mes données ont été cryptées et je devais payer une rançon pour les récupérer. Heureusement, tout était sauvegardé et je n’ai eu qu’à réinitialiser le serveur et tous réinstaller. Mais le temps que je m’en aperçoive et que je fasse ces manipulations, il y a eu une interruption de la réception des ticks (qui a été rattrapée grâce aux données d’autres membre, notamment Robinhood)
Edit : ma clé api est cryptée dans le logiciel.

Si on peut avoir 40 souscriptions, pourquoi tu les prend pas ?
Au départ, cette collecte d’historique était toute personnelle et ne concernait que mon propre projet.
J’ai donc commencé par les trois indices qui m’intéressaient : CAC, DAX, DOW.
Ensuite, j’en ai ajouté quelques uns suite à des demandes particulières.
Mais je les limite pour des questions de stockage et pour ne pas ralentir la récupération des ticks qui m’intéressent vraiment.

Si un jour, tu as envie d'ouvrir un socket pour qu'on puisse s'échanger des flux, c'est un truc qui pourrait m'intéresser.
C’est une belle idée, mais je ne dispose que de très peu de temps et la récupération des historiques n’est pas une fin en soit pour moi. Maintenant que ça tourne correctement, je préfère réserver mon peu de temps disponible à la suite de mon projet.

@Robinhood et -:
Oui en effet Robinhood a utilisé 2 initiales qui nous servent pour envoyer le message demandant de lire le message de bienvenue.

Non, je ne récupère que UTM, Bid et OFR.
Je n'ai pas besoin des autres données et cela allège le traitement.
le volume m'aurait été utile mais je ne comprends pas à quoi correspond cette donnée qui n'est pas systématiquement présente. De plus, sachant que l'on ne récupère qu'une partie des ticks, elle aurait été forcément fausse. Je contourne le problème dans mes algorithmes en considérant le nombre de ticks reçus par seconde qui me donne a peu près la même info que le vrai volume, à savoir s'il y a une accélération ou un ralentissement des transactions. Je pars du principe que l'on doit forcément prendre une décision en se basant sur un sous-ensemble de données (puisqu'on ne reçoit qu'une partie des ticks réels, en gros 4 ticks par seconde) et que cette approximation qui me donne quand même une tendance doit me suffire.

Quand tu expliques que tu as diminué ton nombre de souscriptions pour que ça aille plus vite, est-ce tu pense qu'ig te réduit le débit de tes flux si tu en souscris trop ?
(ou est-ce que c'est pour gagner en vitesse de traitement dans ton propre logiciel ?)
Je n’ai aucune indication qu’ig réduise le débit volontairement ou automatiquement. J’essaie simplement de rendre mon outil de récupération le plus léger et le plus efficient possible afin de laisser la plus grande part des ressources disponibles à l’algorithme de prise de décision. Je développe sur une machine rapide mais l’exploitation se fait sur un VPS qui n’a pas la même puissance.

"je les limite pour des questions de stockage "
Je tenais à stocker mes historiques dans le cloud (et même à l’époque, simultanément dans plusieurs clouds) et je cherchais à ne pas dépasser les limites de stockage gratuit. Le stockage dans le cloud permet aussi un partage simplifié, en fournissant juste un lien.
Depuis, j’ai évolué : après une comparaison des performances des divers clouds, j’ai opté pour un seul abonnement à Dropbox et j’ai activé une sauvegarde locale sur un NAS.

je te conseillerai de stocker tes ticks via Berkeley DB (ou MapDB)
Je stocke les ticks à plat dans de simples fichiers CSV, un par jour et par instrument.
C’est pour moi le meilleur compromis :
1. C’est moins rapide qu’un stockage directement en binaire (puisqu’il faut une conversion à chaque lecture) mais on ne dépend pas d'un format propriétaire, c’est facilement contrôlable visuellement et, surtout, exploitable rapidement avec un tableur.
2. C’est beaucoup plus efficace que n’importe quelle base de donnée car on s’affranchit de l'installation, et de tous les traitements d’indexation et autres dont on n’a pas besoin pour backtester des stratégies de trading, ce qui est mon utilisation (lecture des données séquentiellement). De plus, on n'est pas à la merci d'une boite noire qui peut ne pas évoluer au même rythme que notre environnement de développement.

---
En résumé, je simplifie au maximum la problématique de la récupération et du stockage des ticks pour ne plus avoir besoin de m'en préoccuper et pouvoir me concentrer pleinement sur le développement de stratégies de trading.

Merci, ça pourra m'intéresser pour d'autres applications.

ig ne communique jamais sur son volume (tu serais surpris)

Donc ils reprennent le volume des futures (ce qui est d'ailleurs le seul pertinent car seuls les futures font bouger quelques choses).

Enfin les ticks n'ont rien à voir avec les volumes.

1 tick = une variation du cours. Il peut varier avec 1 ou 500 lots (volume de 1 ou de 500)

"Est-ce que tu penses que tu pourrais ajouter le volume dans ton logiciel ?"
Fait depuis hier soir

Merci

et rien ne vous dit qu"on n'a pas deux flux :
les clients qui tradent en réel et qui font gagner de l'argent et donc qui ont une clé api débridée
les traders en démo qui ne rapportent rien à ig et qui coûtent au contraire de l'argent et qui ont une clé api bridée

on l'a déjà fait - à 50 exemplaires, ça correspond au volume des futures, pour cela que je ne réponds pas, réinventer le couteau à couper le beurre tous les 2 mois ça fatigue

"Tes données proviennent du réel ou de demo ?"
Réel, le mécanisme étant plus stable et les données plus fiables.

HELP !

Suite à un problème sur mon VPS, les ticks n'ont pas été récupérés depuis le 10 mai 2021.

Si une bonne âme qui en dispose pouvait me les envoyer, je pourrais compléter l'historique.

2021-05-20_09-52-14.jpg (3.7 Kio) Vu 560 fois

Merci !

PS : peu importe le format, je me débrouillerais.

Merci quand même d'avoir répondu !
Peut être que Robinhood...

up

https://1drv.ms/u/s!Apct-MPjRX6C2txNwhKk_Wx4gaQNbQ?e=Qj0sXT

C'est maintenant ok
Merci Robinhood !

Le flux chart:tick (mode distinct) est un flux presque en live avec un nouveau message à chaque changement de Bid/ask.
Suffit de m’occuper nq et eu50 pour bien voir la différence.

Le flux chart: 1minute (mode merge) (de mémoire pour le nom je ne suis pas derrière mon ordi) est un flux « pulsé toute les 1 secondes.
Donc je ne vois pas trop comment le flux « pulse » pourrait être mieux ? Je ne comprend pas bien y’a remarque ?

Jill ou un nom de pseudo comme ça avait aussi montré que le flux chart:tick de l’api public est moins riche en tick que le flux utilisé sur la profit factor web avec la version « privée » de l’api. Après faut pas se faire peur non plus il manquait que un ou deux tick de temps en temps et souvent lors des pics de volat’.