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

Salut Takapoto,
Il semble qu'il y ait un bug sur les données du Dow pour la journée du 13 octobre 2020.
Les données sont entremêlées, avec un spread qui oscille très rapidement.

C'est corrigé.
Merci à toi pour l'avoir signalé et à Robinhood pour m'avoir fourni les bonnes données.

C'est moi qui te remercie Taka!

J'ai remarqué aussi qu'il manque les données du nasdaq pour la journée du 6 mai 2020.

En effet !
Mais je ne dispose plus des données brutes de cette date pour recréer cet historique

Je vais voir si je peux recréer les données du nasdaq (de façon approximative) à partir des données du Dow, du Dax et du CAC de cette journée, en utilisant une analyse en composantes principales.

Robinhood m'a signalé un souci avec le NDX du 30/10/2020 et m'a fourni les données pour le corriger.
C'est fait.
Merci à lui !

Hello -,

Je me permets de t'apporter quelques réponses.

Oui Taka partage toujours ses datas. Voici le lien :

https://www.dropbox.com/sh/1zebvv39rg5h87e/AABB0Y_W1v63wd8VfJks9oNla?dl=0

Oui parfois il peut arriver que Takapeek ait des interruptions de données. Dans ce cas là Tala se tourne vers les utilisateurs qui utilisent aussi Takapeek. C'est mon cas mais pas que. Ça m'est arrivé plusieurs fois de le dépanner. Mais ces occurrences sont rares car Takapeek est très fiable. Tu as le bon esprit sur cette approche.

Ce qui est dit sur l'amélioration de cours ne marchant pas via l'API est archi faux. J'ai passé des milliers d'ordres et c'est exactement le même moteur d’exécution, peu importe que tu passe par la plateforme ig, par prt ou autre intermédiaire, ou par l'API.

Concernant tes pbs de limitations, tu peux créer plusieurs clés API pour contourner le problème. ig a une tolérance là dessus.

A+

J'ajouterai juste que les éventuelles données manquantes dans TakaPeek ne sont pas dues à des problème de connexion avec l'Api IG mais à d'autres problèmes (arrêt du serveur, mauvais paramétrage, piratage (oui !), etc...)

Le flux ig est très fiable. Quelques déconnexions se produisent de temps en temps, il suffit d'intercepter les message d'erreur et de se reconnecter immédiatement.

Bien que le choix de ton pseudo qui singe une personne ayant beaucoup souffert du trading et du monde du trading ne m'y prédispose pas énormément, je te réponds tout de même sur le problème des déconnexions de Lightstreamer.

Le Heartbeat n'est pas fiable : tu ne peux pas l'utiliser pour détecter le anomalies du flux.

La solution que j'ai implémentée et qui me donne satisfaction est la suivante :
1) Une variable, alimentée par les codes retour des fonctions REST et Lightstreamer, indique si la connexion est active ou non (*)
2) Un timer se déclenche toutes les x secondes
3) Il teste cette variable et si elle indique que la connexion n'est plus active, le programme se reconnecte automatiquement.

(*) Evènements Lightstreamer à tester pour positionner l'indicateur :
- OnClose
- OnConnectionEstablished
- OnFailure

,

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