Granularité des ticks rendus par l'API IB

Bonjour à tous
Je me suis lancé depuis 3-4 mois dans l'écriture d'un bot de trading en python. Il est connecté à ib via TWS et son API python.
Je me rends compte tout juste qu'il y a une limitation que je n'avais pas identifiée au départ sur la granularité du tyck by tick restitué par l'api reqTickByTickData. En effet certains ticks sont agrégés en 1 seul, très probablement pour réduire le nombre de ticks à streamer (?). D'après mes observations et comparaisons avec les données prt, les ticks agrégés ont le même price et ont la même heure (à la seconde près, ce qui n'est pas super précis). Quand je reconsitue des bougies 100-ticks ç partir de ces ticks, j'ai donc une grosse différence avec les bougies 100-tiks de prt, qui elles sont bonnes.

D'où plusieurs questions :
- comment récupérer des bougies 100 ticks (par exemple) avec l'API ib ? Y en a t-il parmi vous qui le font ?
- sinon quel API utilisez-vous pour récupérer vos données en temps réel ? Autre broker ?
- et même question pour récupérer de l'historique (utile pour les backtests) ?

Grand merci à vous tous

De mémoire il y a vaut eu un débat sur le
Sujet.

En résumé ib stream uniquement de l’agrégé. C’est pas un flux pro en vrai tick by tick.

Bonjour

tu peux faire une recherche, je l'ai expliqué 50 fois au moins, tu auras des réponses détaillées

ib stream les cours à hauteur de 4 ticks par seconde en moyenne (il l'indique sur leur site)

prt donne tous les ticks si tu mets le flux premium donc tu peux en avoir 20 57 89 par secondes

Donc chez ib en direct ils sont de toute façon incomplets et on ne peut pas scalper en ticks avec

Bonjour,
C'est une question intéressante. J'utilise l'API de ib pour expérimenté du trading algo en python depuis 6 mois. J'avais au début constaté la même chose à propos des ticks. J'avais mis cette question de côté car je suis sur des ut plus grand pour le moment 5 minutes et plus.
ib n'est pas un fournisseur de données. Il propose ce service par intermédiaire d'une autre société (voir dans les configuration le nom est indiqué). Ce n'est pas sa spécialité. Cela est aussi précisé à un endroit dans la doc de l'API (je ne sais plus où).

Il y a eu une discussion à ce propos intitulé ""granularity of ticks " sur le groupe de discussion TWS API https://groups.io/g/twsapi/topic/99129776#51241 . D'ailleurs ce post est initié par un une personne française à peu près à la même date (25 mai 2023). Peut être est-ce ta question?
Voici une partie de ce qui est dit pour répondre à la question et en savoir plus (après voir le fil de discussion):

Spoiler:

(While ib is a broker offering a multitude of additional services, and ib never advertised themselves as data provider but as instruments handler)

Nanex deliver raw data directly, there is a need to format the data to an output. (generally a DB)
As data analysis are done in soft aside of the feeder,: ib or Nanex or whatever, anyway, this is theses pieces that need a link to the feed. ib being one of theses.

Nanex is last step before direct market access, understand that NxCore traffic is the range of 2GB a day for Regular Trading Hours.
The kind of DB to use, need to be able to handle TB of datas. (or you need to stay restricted to the range of ~100 of instruments.)

The level of tick granularity you seems to look for require to carefully consider the amount of data you will have to deal with.
If ib does pack ticks it is for good reasons, to offer a generally decent tradeoff between data rate and content richness.

I suspect that you should consider polygon.io, Even if slower and less real time, it is seems easier to link the REST HTTP world to your apps than the C word, also it will be more easy for you to call just the data set you need.

La data est une question en apparence simple mais en fait compliquée. C'est un métier en soi. Cela implique de grosse quantité de donnée à traiter et à mettre en forme pour l'exploiter. Cela prend du temps et nécessite de l'expérience. Si on rajoute le facteur temps avec les ticks cela se complique encore plus. Python ne sera peut être pas assez performant. Au niveau du traitement du tick, il est plus souvent évoquer le C/C++.

Présentation de xeebee le 29 mai:
presentation-de-xeebee-t55428.html#p2001327

@xeebee : oui c'est moi qui ai posté le message sur groups.io Pour moi, ce n'est pas clair de savoir à quel fournisseur on peut s'adresser pour avoir une API fiable qui restitue l'intégralité des ticcks avec une faible latence (besoin du temps réel). Les tests que je fais en ce moment avec ib me donnent un délai de réception des ticks de l'ordre de 2sec alors que je ping à 100ms un serveur de chicago... (je suis en Fibre avec une latence de 20ms sur les speedtests nperf ). Bref je vais faire avec ces limitations mais quand j'aurai du temps je verrai pour trouver mieux...ça n'a pas l'air simple à trouver.
@Benoist : Même si ib est effectivement bien en-dessous de prt en terme de granularité des ticks, mes tests sont plus optimistes que les chiffres que tu donnes. Par exemple lors de l'ouverture d'hier vendredi à 15:30:00, l'API reqTickByTicks m'a retourné 183 ticks, puis 138 ticks la seconde suivante, etc. Donc on a quand même une excellente précision, même si elle n'est suffisante pour reconstituer les bougies en 100 ticks...
Je galère pas mal sur ce sujet, j'espère que ces quelques infos pourront être utiles aux membres de ce forum qui m'a déjà beaucoup apporté