开云体育

I am not disputing your results, but you are now comparing reqMktData() tick #48 "RtVolume" with the tick-by-tick feed from Databento.? But our discussion here is about reqTickByTick() which is

Okay thank you for clarifying. $30 for 3 months is not bad at all. I checked out Portara CQG a couple months back for /NQ & /ES and I believe it was $895 per instrument going back to 2014 for level 1

Shoot i was hoping markdown formatted tables worked. :/

Yea in realtime I'm just getting the ticks from ibkr via reqTickByTick. Databento does provide live data but I have not subscribed to it. Apologies, it is relevant that the data is not consistent

So, in real-time though, assuming your backtest went well and you are now running in realtime, you are using reqTickByTick()? Or are you using a live datastream from databento, if it's even offered,

I also found the same issue as you where the historical ticks are rounded to the 1 second, and after much searching couldn't find any way to get higher resolution from ibkr. I wasn't sure that I

Will do this week. Interesting finds there on /ES. Do you also work with machine learning? If so, how has your experience been with it? <TwsApiOnGroupsIo@...> wrote:

On top of the (excellent) reply by Jürgen, please be aware that the "50 messages per second" limitation applies to all messages combined. Do not think that you can send e.g. 50 placeOrder() and 50

Let me give a little different view than the previous respondents. In my experience, there is no need to pace requests or to add any delay when making TWS API requests with two documented exceptions

Sounds similar to what I have been banging my head against. As I said in my post. You should be able to filter the additional ticks out of reqHistoricalTicks() and convert them to streams that are

Also, most of my live strategies are written in a C++ Client application I wrote for IB communications, etc. It's built with Cmake to run on linux. But backtesting is done in python.

Jurgen, Yes definitely a complicated task with a lot of considerations both in backtest and application. I do need to compare the 2 functions' data streams of reqHistoricalTicks() and reqTickByTick()

While your post is quite short, you include a lot of interconnected details that probably cause the "fuzziness" and unspecific answers by API support. So let's try and "divide and conquer". What kind

For child orders I used to get the error referring to parent order unavailability until I arrived by way of experiment to a pause of a whopping 800 ms after parent order submission (to be fair, I do

You can use Pair trade hedge type (Order.HedgeType = "P") which allows setting different quantities for the orders via the Order.HedgeParam property (as a ratio between the two order sizes). To ensure

I do see multiple tick entries for the same timestamp with different price and size values though in my historical tick data that's the problem. So, its not exactly matching to 1 second bars. I need

Hi, I have discussed this with the API support team, but I am still fuzzy and was not given the most clear answer. I am backtesting a strategy where the data has been collected using

Hi Andy. I also introduce 10ms of delay across orders. So far, working well for years. For other requests with `reqId`, I don't apply delay but I have a pacer that will introduce 1000ms delay every 45

There are a couple of pages mentioning limits on historical requests and orders. TWS API v9.72+: Historical Data Limitations ( https://interactivebrokers.github.io/tws-api/historical_limitations.html

It's very weird that the TWS API doesn't provide this information but, fortunately, this information is actually available at https://www.interactivebrokers.com/en/trading/products-exchanges.php