开云体育

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

Suppose I have a standing limit buy order for a stock X, and a "child" limit sell order for a stock Y. ?I've submitted them as a hedge pair, so that the (child) order for Y is dormant until the

I bought 63 shares of SNAP at 12.75. I then sent 2 STP calls; one at 12.85 and another at 12.57 (see below). The price crossed 12.85 but the SELL order was never executed. Any idea

Thanks. ?They are indeed limit orders, but the limit prices are updated frequently, so the condition parameters would also have to be updated dynamically to keep them in sync. ?In principle that

I assume your BUY and SELL orders are limit orders (or something similar). If entry prices are known in advance and far enough apart, maybe order conditioning with two conditions may work: * the

Hello, Please see:? https://www.hhssoftware.com/iabsocketapi/index.php

Jürgen, Thank you for the suggestion. ?I tried it, but IBKR rejected it with the following message: Order rejected - reason:Child must have the same contract as parent order., contract=None In my