Re: What is the exact limit on number of requests?
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 requests. For my needs that's enough.
Hope it helps, Daniel.
On Sat, Jan 11, 2025 at 3:13?AM Andy Sanders via <arteinvolo= [email protected]> wrote: There are a couple of pages mentioning limits on historical requests and orders.?
?
The last link mentions that I should be able to place up to 50 requests per seconds.?
Meanwhile, when trying to sell iron condor using 4 independent orders, only some of them are being submitted and if I try to wait until all of them are placed, my script hangs.?
Then, I tried to add some delay between placing orders, and now all of them are placed as expected.?
?
for (var i = 0; i < orders.Count; i++)
{
? client.ClientSocket.placeOrder(...)
? await Task.Delay(15)?
}?
?
It seems that a delay of 15 milliseconds is enough.
Anything less than that gets stuck on the way to TWS.?
The same limitations seems to apply to "reqMktData" and "reqContractDetails" calls.?
?
Question?
?
How reliable is this hardcoded delay of 15 ms.?
Is there a recommended delay between requests anywhere in the docs??
|
What is the exact limit on number of requests?
There are a couple of pages mentioning limits on historical requests and orders.?
?
The last link mentions that I should be able to place up to 50 requests per seconds.?
Meanwhile, when trying to sell iron condor using 4 independent orders, only some of them are being submitted and if I try to wait until all of them are placed, my script hangs.?
Then, I tried to add some delay between placing orders, and now all of them are placed as expected.?
?
for (var i = 0; i < orders.Count; i++)
{
? client.ClientSocket.placeOrder(...)
? await Task.Delay(15)?
}?
?
It seems that a delay of 15 milliseconds is enough.
Anything less than that gets stuck on the way to TWS.?
The same limitations seems to apply to "reqMktData" and "reqContractDetails" calls.?
?
Question?
?
How reliable is this hardcoded delay of 15 ms.?
Is there a recommended delay between requests anywhere in the docs??
|
Re: How to get a list of symbols of all product available?
It's very weird that the TWS API doesn't provide this information but, fortunately, this information is actually available at without any authentication. Here is a very simple scraper I wrote to pull this info:
?
?
|
how to make price updates for two related standing orders take effect within 10ms of each other?
?
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 (parent) order for X is filled, at which point IBKR servers activate the order for Y.
?
Now, while waiting for the order for X to execute, I am frequently (and programmatically, via TWS api) updating the limit prices. ?With each update, I update the limit prices of the parent and child at the same time.
?
Ideally, for each update, I would like it to take effect on the two orders simultaneously. ?Say within 10 milliseconds of each other. ? But this doesn't happen. ?Even though I submit the two price changes to my locally running TWS within ms of each other, they often take effect at IBKR say, 40-100ms apart. ?Hence, when the parent order fills, and IBKR activates the child order, it often happens that the limit price of the child order (for Y) is out of sync with the price at which the parent order (for X) filled.
?
Question: What can I do, if anything, to reduce or mitigate this effect?
?
In the spirit of brainstorming, here are some (bad?) ideas:
?
1. IBKR does have some "algorithmic" orders that calculate price updates at their servers. ?Presumably if I could use those it would help, because the calculations and updates would be done server-side. ?However, none of their algorithmic order types matches what I need. ?At least, not in any direct way that I can see.
?
2. Another approach might be to try to set the limit prices more conservatively somehow. ?There are two possible bad outcomes when the parent fills, namely:
?
Bad outcome 1: ?the child (sell Y) order is activated with a limit price that is too low, and it fills, but at a lower cost than it should have.
?
Bad outcome 2: the child (sell Y) order is activated with a limit price that is too high, and it doesn't fill, and meanwhile the price of Y moves down.
?
These two bad outcomes are most likely when the prices of X and Y are changing rapidly. ?The outcomes have different risk profiles, so perhaps adjusting the limit prices somehow to decrease the probability of one at the expense of increasing the probability of the other might somehow be helpful, although I'm not sure how to do that in a systematic way.
?
3. Maybe the offset in time between when the two changes take effect is somewhat predictable. ?In that case, in principle I could delay the submission of the "faster" of the two price updates to bring their likely "arrival" times closer.
?
?
Thanks,
?
-Neal
|
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 why?
?
Thanks
?
3-72-0-SNAP-STK--0.0---SMART-NYSE-USD-----BUY-63-LMT-12.75------0--1-0-0-0-0-0-0-0--0-------0---1-0---0---0-0--0------0-----0-----------0---0-0---0--0-0-0-0--1.7976931348623157e+308-1.7976931348623157e+308-1.7976931348623157e+308-1.7976931348623157e+308-1.7976931348623157e+308-0----1.7976931348623157e+308-----0-0-0--2147483647-2147483647-0----0--2147483647-
16:24:10:544 (sync 16:24:10:951) <- 8-1--1-
16:24:10:544 (sync 16:24:10:951) <- 5-1-
16:24:10:644 (sync 16:24:11:051) -> ---9-1-73-
16:24:10:744 (sync 16:24:11:151) -> --- 3-72-ApiPending-0-63--0-0--0---
16:24:10:744 (sync 16:24:11:151) -> ---53-1-
16:24:10:932 (sync 16:24:11:339) -> --?5-72-268060148-SNAP-STK--0-?--SMART-USD-SNAP-SNAP-BUY-63-LMT-12.75-0.0-DAY--U19XXXXX--0--0-1789987302-0-0-0--1789987302.0/U19XXXXX/100---------0---1-0------2147483647-0-0-0--3-0-0--0-0--0-None--0----?-0-0--0-0------0-0-0-2147483647-2147483647---0--IB-0-0--0-0-PreSubmitted-1.7976931348623157E308-1.7976931348623157E308-1.7976931348623157E308-1.7976931348623157E308-1.7976931348623157E308-1.7976931348623157E308-1.7976931348623157E308-1.7976931348623157E308-1.7976931348623157E308------0-0-0-None-1.7976931348623157E308-13.75-1.7976931348623157E308-1.7976931348623157E308-1.7976931348623157E308-1.7976931348623157E308-0----0-1-0-0-0---0--100-0.02----0------3-72-PreSubmitted-0-63-0-1789987302-0-0-0--0-
16:24:10:937 (sync 16:24:11:344) -> ---?11--1-72-268060148-SNAP-STK--0.0---NASDAQ-USD-SNAP-SNAP-00010193.678154be.01.01-20250110 10:24:11 US/Eastern-U19XXXXX-NASDAQ-BOT-63-12.75-1789987302-0-0-63-12.75-----2-0-
16:24:10:940 (sync 16:24:11:347) -> --?5-72-268060148-SNAP-STK--0-?--SMART-USD-SNAP-SNAP-BUY-63-LMT-12.75-0.0-DAY--U19XXXXX--0--0-1789987302-0-0-0--1789987302.0/U19XXXXX/100---------0---1-0------2147483647-0-0-0--3-0-0--0-0--0-None--0----?-0-0--0-0------0-0-0-2147483647-2147483647---0--IB-0-0--0-0-Filled-1.7976931348623157E308-1.7976931348623157E308-1.7976931348623157E308-1.7976931348623157E308-1.7976931348623157E308-1.7976931348623157E308-1.7976931348623157E308-1.7976931348623157E308-1.7976931348623157E308------0-0-0-None-1.7976931348623157E308-13.75-1.7976931348623157E308-1.7976931348623157E308-1.7976931348623157E308-1.7976931348623157E308-0----0-1-0-0-0---0--100-0.02----0-----/3-72-Filled-63-0-12.75-1789987302-0-12.75-0--0-
16:24:10:942 (sync 16:24:11:349) -> --?5-72-268060148-SNAP-STK--0-?--SMART-USD-SNAP-SNAP-BUY-63-LMT-12.75-0.0-DAY--U19XXXXX--0--0-1789987302-0-0-0--1789987302.0/U19XXXXX/100---------0---1-0------2147483647-0-0-0--3-0-0--0-0--0-None--0----?-0-0--0-0------0-0-0-2147483647-2147483647---0--IB-0-0--0-0-Filled-1.7976931348623157E308-1.7976931348623157E308-1.7976931348623157E308-1.7976931348623157E308-1.7976931348623157E308-1.7976931348623157E308-1.7976931348623157E308-1.7976931348623157E308-1.7976931348623157E308-1.002205---USD--0-0-0-None-1.7976931348623157E308-13.75-1.7976931348623157E308-1.7976931348623157E308-1.7976931348623157E308-1.7976931348623157E308-0----0-1-0-0-0---0--100-0.02----0-----/3-72-Filled-63-0-12.75-1789987302-0-12.75-0--0-
16:24:10:943 (sync 16:24:11:350) -> ---Y59-1-00010193.678154be.01.01-1.002205-USD-1.7976931348623157E308-1.7976931348623157E308--
16:24:13:549 (sync 16:24:13:956) <- 8-1--1-
16:24:13:551 (sync 16:24:13:958) -> ---9-1-73-
16:24:13:552 (sync 16:24:13:959) <- 3-73-0-SNAP-STK--0.0---SMART-NYSE-USD-----SELL-63-STP-12.75-12.85-----0--1-0-0-0-0-0-0-0--0-------0---1-0---0---0-0--0------0-----0-----------0---0-0---0--0-0-0-0--1.7976931348623157e+308-1.7976931348623157e+308-1.7976931348623157e+308-1.7976931348623157e+308-1.7976931348623157e+308-0----1.7976931348623157e+308-----0-0-0--2147483647-2147483647-0----0--2147483647-
16:24:13:553 (sync 16:24:13:960) <- 8-1--1-
16:24:13:553 (sync 16:24:13:960) <- 5-1-
16:24:13:553 (sync 16:24:13:960) <- 8-1--1-
16:24:13:556 (sync 16:24:13:963) <- 3-73-0-SNAP-STK--0.0---SMART-NYSE-USD-----SELL-63-STP-12.75-12.57-----0--1-0-0-0-0-0-0-0--0-------0---1-0---0---0-0--0------0-----0-----------0---0-0---0--0-0-0-0--1.7976931348623157e+308-1.7976931348623157e+308-1.7976931348623157e+308-1.7976931348623157e+308-1.7976931348623157e+308-0----1.7976931348623157e+308-----0-0-0--2147483647-2147483647-0----0--2147483647-
16:24:13:557 (sync 16:24:13:964) <- 8-1--1-
16:24:13:557 (sync 16:24:13:964) <- 5-1-
16:24:13:568 (sync 16:24:13:975) -> ---9-1-74-
16:24:13:653 (sync 16:24:14:060) -> --?5-73-268060148-SNAP-STK--0-?--SMART-USD-SNAP-SNAP-SELL-63-STP-12.82-12.85-DAY--U19XXXXX--0--0-1789987303-0-0-0--1789987303.0/U19XXXXX/100---------0---1-0------2147483647-0-0-0--3-0-0--0-0--0-None--0----?-0-0--0-0------0-0-0-2147483647-2147483647---0--IB-0-0--0-0-PendingSubmit-1.7976931348623157E308-1.7976931348623157E308-1.7976931348623157E308-1.7976931348623157E308-1.7976931348623157E308-1.7976931348623157E308-1.7976931348623157E308-1.7976931348623157E308-1.7976931348623157E308------0-0-0-None-1.7976931348623157E308-12.85-1.7976931348623157E308-1.7976931348623157E308-1.7976931348623157E308-1.7976931348623157E308-0----0-1-0-0-0---0--100-0.02----0-----.3-73-PendingSubmit-0-63-0-1789987303-0-0-0--0-
16:24:13:653 (sync 16:24:14:060) -> ---53-1-
16:24:13:688 (sync 16:24:14:095) -> --?5-73-268060148-SNAP-STK--0-?--SMART-USD-SNAP-SNAP-SELL-63-STP-12.82-12.85-DAY--U19XXXXX--0--0-1789987303-0-0-0--1789987303.0/U19XXXXX/100---------0---1-0------2147483647-0-0-0--3-0-0--0-0--0-None--0----?-0-0--0-0------0-0-0-2147483647-2147483647---0--IB-0-0--0-0-PreSubmitted-1.7976931348623157E308-1.7976931348623157E308-1.7976931348623157E308-1.7976931348623157E308-1.7976931348623157E308-1.7976931348623157E308-1.7976931348623157E308-1.7976931348623157E308-1.7976931348623157E308------0-0-0-None-1.7976931348623157E308-12.85-1.7976931348623157E308-1.7976931348623157E308-1.7976931348623157E308-1.7976931348623157E308-0----0-1-0-0-0---0--100-0.02----0-----43-73-PreSubmitted-0-63-0-1789987303-0-0-0-trigger-0-
16:24:13:753 (sync 16:24:14:160) -> ---9-1-74-
16:24:13:953 (sync 16:24:14:360) -> ---9-1-74-
16:24:13:973 (sync 16:24:14:380) -> --?5-73-268060148-SNAP-STK--0-?--SMART-USD-SNAP-SNAP-SELL-63-STP-0.0-12.57-DAY--U19XXXXX--0--0-1789987303-0-0-0--1789987303.1/U19XXXXX/100---------0---1-0------2147483647-0-0-0--3-0-0--0-0--0-None--0----?-0-0--0-0------0-0-0-2147483647-2147483647---0--IB-0-0--0-0-PreSubmitted-1.7976931348623157E308-1.7976931348623157E308-1.7976931348623157E308-1.7976931348623157E308-1.7976931348623157E308-1.7976931348623157E308-1.7976931348623157E308-1.7976931348623157E308-1.7976931348623157E308------0-0-0-None-1.7976931348623157E308-12.57-1.7976931348623157E308-1.7976931348623157E308-1.7976931348623157E308-1.7976931348623157E308-0----0-1-0-0-0---0--100-0.02----0-----43-73-PreSubmitted-0-63-0-1789987303-0-0-0-trigger-0-
16:24:14:053 (sync 16:24:14:460) -> --?5-73-268060148-SNAP-STK--0-?--SMART-USD-SNAP-SNAP-SELL-63-STP-0.0-12.57-DAY--U19XXXXX--0--0-1789987303-0-0-0--1789987303.1/U19XXXXX/100---------0---1-0------2147483647-0-0-0--3-0-0--0-0--0-None--0----?-0-0--0-0------0-0-0-2147483647-2147483647---0--IB-0-0--0-0-PreSubmitted-1.7976931348623157E308-1.7976931348623157E308-1.7976931348623157E308-1.7976931348623157E308-1.7976931348623157E308-1.7976931348623157E308-1.7976931348623157E308-1.7976931348623157E308-1.7976931348623157E308------0-0-0-None-1.7976931348623157E308-12.57-1.7976931348623157E308-1.7976931348623157E308-1.7976931348623157E308-1.7976931348623157E308-0----0-1-0-0-0---0--100-0.02----0-----43-73-PreSubmitted-0-63-0-1789987303-0-0-0-trigger-0-
16:24:14:053 (sync 16:24:14:460) -> ---53-1-
16:38:00:671 (sync 16:38:00:731) <- 8-1--1-
16:38:00:671 (sync 16:38:00:731) -> ---9-1-74-
16:38:00:672 (sync 16:38:00:732) <- ?5-73-268060148-SNAP-STK--0-?--SMART-USD-SNAP-SNAP-SELL-63-STP-0.0-12.57-DAY--U19XXXXX--0--0-1789987303-0-0-0--1789987303.1/U19XXXXX/100---------0---1-0------2147483647-0-0-0--3-0-0--0-0--0-None--0----?-0-0--0-0------0-0-0-2147483647-2147483647---0--IB-0-0--0-0-PreSubmitted-1.7976931348623157E308-1.7976931348623157E308-1.7976931348623157E308-1.7976931348623157E308-1.7976931348623157E308-1.7976931348623157E308-1.7976931348623157E308-1.7976931348623157E308-1.7976931348623157E308------0-0-0-None-1.7976931348623157E308-12.57-1.7976931348623157E308-1.7976931348623157E308-1.7976931348623157E308-1.7976931348623157E308-0----0-1-0-0-0---0--100-0.02----0-----43-73-PreSubmitted-0-63-0-1789987303-0-0-0-trigger-0-
|
Re: conditional order conditioned on execution of buy order only?
?
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 sounds doable, but I have some related experience that suggests that in practice, even when updates to two standing trades are submitted simultaneously, the updates often take effect at different times, so that the two trades are regularly out of sync for 10-100 ms periods. ?My prior is that during these times (in your proposed scenario), when the PriceCondition price (someValue) gets out of sync, there could be a non-negligible chance of triggering the wrong conditional order. ?That could have a high cost.
?
My current strategy does have the same risk of out-of-sync periods, but the bad potential outcomes are not as costly.
?
Meanwhile, I think I found a workaround to my original issue. ?That issue was that when I first submit the hedge order's child, I cannot set any displayed size for the child. ?(That's why I wanted to find an alternative to the hedge pair.) ?But apparently I can set the displayed size subsequently?just by updating the order. ?At least, I've been trying that for a few hours and it seems to be working.
?
Keeping separate orders in sync while updating them is an interesting but separate topic. ?I will start a new thread about it.
?
Thank you ´³¨¹°ù²µ±ð²Ô,
?
-Neal
?
?
|
Re: conditional order conditioned on execution of buy order only?
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 ExecutionCondition you were trying
- plus a PriceCondition that identifies that the BUY order triggered (Price < someValue)
- combined with AND
Quantities for these orders would be independent in the sense that the conditioned order would try to execute its quantity even if the triggering order fills only partially.
?
Just a thought.
´³¨¹°ù²µ±ð²Ô
?
On Fri, Jan 10, 2025 at 06:31 AM, Neal Young wrote:
?
´³¨¹°ù²µ±ð²Ô,
?
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 case, the child order and the parent order are not for the same stock, so I need the child and parent orders to have different contracts.
?
I'd been using a hedge pair, which does allow that. ?It has the drawback that the displayed size of the child cannot be set at the time of creation, but I may be able to work around that.
?
-Neal
|
Hello,
?
Please see:? https://www.hhssoftware.com/iabsocketapi/index.php
|
Re: conditional order conditioned on execution of buy order only?
?
´³¨¹°ù²µ±ð²Ô,
?
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 case, the child order and the parent order are not for the same stock, so I need the child and parent orders to have different contracts.
?
I'd been using a hedge pair, which does allow that. ?It has the drawback that the displayed size of the child cannot be set at the time of creation, but I may be able to work around that.
?
-Neal
|
Re: conditional order conditioned on execution of buy order only?
I don't think your idea with two client connections will work. ExecutionCondition decisions are most definitely made within IBKR's infrastructure and not by TWS/IBGW. And at that point, IBKR is only concerned about accounts and orders regardless of how many client connections to TWS/IBGW exist.
?
We don't know all your requirements, but wouldn't a simple order attachment due the trick? You'd attach the order you want to trigger upon execution of the BUY order to the BUY order via parentId. Just like hedge and bracket orders. The child order will not become active until the parent (BUY) executes.
?
´³¨¹°ù²µ±ð²Ô
?
?
On hu, Jan 9, 2025 at 07:56 AM, Neal Young wrote:
I have a question about conditional orders, where the condition is an execution condition, per
?
?
?
The documentation says that the condition is defined by giving a symbol, an exchange, and a security type, and that the condition is met " whenever a trade occurs on the specified product at the given exchange." Per other discussions here (e.g. ´³¨¹°ù²µ±ð²Ô's comment) I assume that the trade must be a trade in the current account (one that would trigger an execDetails message). ?
Here's my question:
?
in the case that I have two standing orders for the symbol, namely a buy order and a sell order, is it possible to have the condition trigger only when the buy order executes (and not when the sell order executes)?
?
(I don't see how, although I did think of one possible workaround: have two separate processes, each with its own connection to TWS, one managing the buy order, the other managing the sell order. ?Then (perhaps?) the execution condition set by the process that placed the buy order would only be triggered if the buy order executes. ?I don't know if this would work (I haven't tested it). ?I don't really want to resort to this, as having two separate processes, each with a separate connection to TWS, would complicate my code quite a bit.)
?
Thanks,
?
Neal
|
Hi
?
Is anyone working with Delphi (pascal) to connect to TWS? I can't connect at all.
?
Thanks
|
conditional order conditioned on execution of buy order only?
I have a question about conditional orders, where the condition is an execution condition, per
?
?
?
The documentation says that the condition is defined by giving a symbol, an exchange, and a security type, and that the condition is met " whenever a trade occurs on the specified product at the given exchange." Per other discussions here (e.g. ´³¨¹°ù²µ±ð²Ô's comment) I assume that the trade must be a trade in the current account (one that would trigger an execDetails message). ?
Here's my question:
?
in the case that I have two standing orders for the symbol, namely a buy order and a sell order, is it possible to have the condition trigger only when the buy order executes (and not when the sell order executes)?
?
(I don't see how, although I did think of one possible workaround: have two separate processes, each with its own connection to TWS, one managing the buy order, the other managing the sell order. ?Then (perhaps?) the execution condition set by the process that placed the buy order would only be triggered if the buy order executes. ?I don't know if this would work (I haven't tested it). ?I don't really want to resort to this, as having two separate processes, each with a separate connection to TWS, would complicate my code quite a bit.)
?
Thanks,
?
Neal
|
Re: same volume for SMART and NYSE or ISLAND in reqMktData
The "Volume" tick does seem to report the same value for @SMART and @NYSE and it includes "Unreportable Trades" since the value is identical to the totalVolume field of the "RtVolume" tick.
But the totalVolume field of the "RtTradeVolume" tick does report exchange specific values similar to reqHistoricalData if that is what you are looking for. Below the last reported Volume, RtVolume, and RtTradeVolume ticks for @SMART and @NYSE from my test.
Also, LastExchange in both feeds properly identifies the source of "Price" ticks so that your client could keep a more detailed picture of the trade distribution across all exchanges the instrument trades on.
´³¨¹°ù²µ±ð²Ô
?
?
On Thu, Jan 9, 2025 at 05:13 AM, ajn wrote:
Thanks ´³¨¹°ù²µ±ð²Ô, very serious work! Very appreciated!
I guess the expectation that the difference between calling @SMART would give info from all exchanges yet @NYSE would give info specific for NYSE. And particular indicator which is expected to be very different is volume. Yet both my test and yours shows that it is basically the same number.?
?
Fortunately, in my case I am only interested in full data. So it is not causing any issues for me. However, like it often happens: "If there is discrepancy between expectation and reality it is worth double checking, very likely there is an issue on my side, I understand it wrong or code it wrong or anything else is wrong on my side". So I approach it only from this angle. If consensus on this forum is?
1. reqHistoricalData will give you very different volume data for @SMART vs @NYSE (SMART having ALL the volume, NYSE only for that specific exchange)
2. reqMktData will give you same volume data no matter if you call it for @SMART or @NYSE, we don't know why (or insert explanation here)
?
I am totally fine with that consensus. Just trying to get rid of bugs/discrepancies one by one in my code/understanding of IB API.?
AJ
|
Re: same volume for SMART and NYSE or ISLAND in reqMktData
Good job ´³¨¹°ù²µ±ð²Ô and AJ. I learnt this today and wanted to say Thank you to you both.? This type of analysis is why we are in the forum.?
Daniel.
Thanks ´³¨¹°ù²µ±ð²Ô, very serious work! Very appreciated!
I guess the expectation that the difference between calling @SMART would give info from all exchanges yet @NYSE would give info specific for NYSE. And particular indicator which is expected to be very different is volume. Yet both my test and yours shows that it is basically the same number.?
?
Fortunately, in my case I am only interested in full data. So it is not causing any issues for me. However, like it often happens: "If there is discrepancy between expectation and reality it is worth double checking, very likely there is an issue on my side, I understand it wrong or code it wrong or anything else is wrong on my side". So I approach it only from this angle. If consensus on this forum is?
1. reqHistoricalData will give you very different volume data for @SMART vs @NYSE (SMART having ALL the volume, NYSE only for that specific exchange)
2. reqMktData will give you same volume data no matter if you call it for @SMART or @NYSE, we don't know why (or insert explanation here)
?
I am totally fine with that consensus. Just trying to get rid of bugs/discrepancies one by one in my code/understanding of IB API.?
AJ
|
Re: same volume for SMART and NYSE or ISLAND in reqMktData
Thanks ´³¨¹°ù²µ±ð²Ô, very serious work! Very appreciated!
I guess the expectation that the difference between calling @SMART would give info from all exchanges yet @NYSE would give info specific for NYSE. And particular indicator which is expected to be very different is volume. Yet both my test and yours shows that it is basically the same number.?
?
Fortunately, in my case I am only interested in full data. So it is not causing any issues for me. However, like it often happens: "If there is discrepancy between expectation and reality it is worth double checking, very likely there is an issue on my side, I understand it wrong or code it wrong or anything else is wrong on my side". So I approach it only from this angle. If consensus on this forum is?
1. reqHistoricalData will give you very different volume data for @SMART vs @NYSE (SMART having ALL the volume, NYSE only for that specific exchange)
2. reqMktData will give you same volume data no matter if you call it for @SMART or @NYSE, we don't know why (or insert explanation here)
?
I am totally fine with that consensus. Just trying to get rid of bugs/discrepancies one by one in my code/understanding of IB API.?
AJ
|
Re: same volume for SMART and NYSE or ISLAND in reqMktData
Some more stats from comparing real-time feeds for MTDR@NYSE and MTDR@SMART on 20250108 between 13:30 and 16:10 US/Central:
- The NYSE feed did not get any 5 second real time bars
- The SMART feed received more than twice the ticks than the NYSE feed
- Several ticks (marked in green) received the same number of ticks and the same data. Except for "Volume" where 3 of the 946 ticks had different values
- Seven tick types were only sent in the SMART feed.
Hope this help,
´³¨¹°ù²µ±ð²Ô
?
|
Re: same volume for SMART and NYSE or ISLAND in reqMktData
I have never looked into this in the first place, but after a quick test with my data recorder I can confirm your observation for the Volume tick as well as all fields of the RtVolume tick. But the data feeds are not identical and other ticks may provide different values.
My quick test:
- Requested MTDR@SMART from an IBGW paper account
- And in parallel MTDR@NYSE from a TWS Paper account
- Over a 15 min periods, SMART had received 1,611 ticks while NYSE received only received 657
- My data recorder requests all available tick types when calling reqMktData
I'll let this run for the rest of the day and, if I can find some time, will drill down a little more.
´³¨¹°ù²µ±ð²Ô
PS. Going forward, please do not attach code to your posts and limit the code inside the posts to the absolute minimum. We are not a Python code exchange, you cannot expect other people to run your code, it makes your posts and the discussion less relevant for the majority of members that use programming languages other than Python, and serious legal and licensing issues can arise.
?
On Wed, Jan 8, 2025 at 12:17 PM, ajn wrote:
?
The question is: is that expected behavior for reqMktData? I was not expecting this, I was expecting same behavior as for reqHistoricalData
|
same volume for SMART and NYSE or ISLAND in reqMktData
In this answer it was pointed out the importance of setting SMART as a contract exchange to get most of the information/volume while using reqMktData. Which I always believed is the correct way, totally agree. However I double checked and found that for reqMktData it doesn't seem to matter. I.e. no matter if I ask for SMART or specific exchange I get the same volume information. Note, this is true only for reqMktData, if I use historical data using reqHistoricalData I see very different volume for SMART vs NYSE/ISLAND just like expected. So not to hijack the original thread maybe we can clear it up here.? ?
If I run the attached program like this >python Program_exchanges.py --port 4001 I get the following output. I.e. looks like I am getting same volume for all exchanges (maybe several lots difference sometimes, I guess it has to do with timing, but definitely not 20-70% volume difference as one would expect having seen historical data).
?
I have tried different stocks. Seems to be true for all I have tried. In case one want to experiment this is how I list the contracts I want data for
 ? and then loop through them and ship go reqMktData
?
The question is: is that expected behavior for reqMktData? I was not expecting this, I was expecting same behavior as for reqHistoricalData
|
Re: 2024 NQ and ES futures historical data
|
Re: 2024 NQ and ES futures historical data
I was using databento.com to get historical data for various futures for periods that were not covered by IB. They provide data for various ticks and charge $28/GB. They also use to give some credit when you sign up that may cover some of your expenses.
toggle quoted message
Show quoted text
On Jan 7, 2025, at 2:20?PM, IBmark via groups.io <ferreira.helhazar@...> wrote:
? Hi everyone,
?
I need to test something and I have been having a bit of trouble requesting data from IB. Does anyone have last year?s historical data for ES and NQ? doesn?t have to be tick data. Alternatively where can I find it cheap and reliable??
?
thanks a bunch.?
|
