Re: reqHistoricalTicks() & batching vs. reqTickByTick() vs. reqHistoricalData(), Backtesting vs. Realtime execution
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? On Sat, Jan 11, 2025 at 11:30?PM ´³¨¹°ù²µ±ð²Ô Reinold via <TwsApiOnGroupsIo= [email protected]> wrote:
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 identical to recorded reqTickByTick() streams for the same period. Just try it for a day or two next week.
I have no recorded natural gas ticks, but here the trade profile for ESH5 last week from recorded reqTickByTick() data:
- There were 2.5Mio trades last week with a total volume of just shy of 7Mio contracts
- 55% of the trades and 20% of the total volume came from trades with a size of 1
- 90% of the trades had a size of 5 or less while 90% of the total volume came from trades with sizes of 25 or less.
- You see there is a "long tail" ending with a trade of 1,895 contracts (just over $555Mio) where you can find "large" trades
´³¨¹°ù²µ±ð²Ô
?
?
?
?
?
?
?
On Sat, Jan 11, 2025 at 09:38 PM, Brendan Lydon wrote:
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() and check feasibility there. My strategy is similar to another classification machine learning model I wrote for 1 minute OHLCV bars which I used to map a bunch of different features and ran in realtime. That was straight forward, as you can stream reqHistoricalData() in realtime for each new bar update on the minute every minute and feed it through the model to get your prediction on the next candle: up or down, and form a strategy around existing positions that way. With this though, I plan to center my classification model around 'large' orders to answer the same question though: up or down, but I want to pass a new x-vector through my trained model on each 'large' order. Assume its a basic logistic regression binary classification problem, so the x-vector I pass into the model will make a signal every time the large order threshold is met. I will obviously set a threshold for 'large', probably dynamic based on current tick-by-tick volumes, say outside 2 standard deviations for example. I want to avoid using bar like data structures like tick-bars, volume bars, imbalance bars, etc. I said a basic logistic regression binary classification model, but in reality it will be probably end up being a multi-class classification model using an LSTM like architecture with classes like: long, short, do nothing. And pass a multi-dimensional vector packing in all tick data and associated, mapped features between large-orders into the next signal. None of the strategy matters though if the data I use in real time is not as close to the data I back test on. And I am worried that a 'large' order defined by the data I am using for the backtest, collected via reqHistoricalTicks(), will approximate parameters for the features I come up with based on values I may never see in realtime if I then decide to use reqTickByTick() making the backtest obsolete with this current data I have. Collecting enough reqTickByTick() data could potentially take years to have a valid dataset to train on if I started collecting now. I hope that clears up my intentions for the strategy and I appreciate your thoughts.
?
Thank you,
Brendan
|
Re: What is the exact limit on number of requests?
On top of the (excellent) reply by ´³¨¹°ù²µ±ð²Ô, 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 reqMktData() in the same second! So, if you decide to code a message-pacer yourself instead of relying on the built-in pacer IBKR provides, you have to combine all outgoing messages from your application software into TWS/Gateway in this pacer.
|
Re: What is the exact limit on number of requests?
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 (that I am aware of):
- When requesting a large number of historical bar data with very small widths you need to observe the Historical Data Download limits
- In case you receive error 10006 "Missing parent order" when placing orders (and I have never experienced this), the TWS API documentation says:
"In some cases this can occur with bracket orders if the child order is placed immediately after the parent order; a brief pause of 50 ms or less will be necessary before the child order is transmitted to TWS/IBG."
There is a limit of 50 requests per second that all clients connected to the same TWS/IBGW together cannot exceed. Again, that is not per client but the aggregate of all clients. And many years back, TWS/IBGW would reject requests that exceeded that rate with an error message. Long-term users of TWS API have, therefore, implemented various pacing schemes so that their clients stay below that rate.
TWS API 9.79 (API level 156, released in early 2020) introduced the connection option "PACEAPI" that instructs TWS/IBGW to accept all client requests even those beyond the acceptable request rate without rejections and errors and to perform any required pacing internally. I have used that option ever since and have never had any issues with missed, dropped, or hanging requests.
Some time during the early V10 versions of TWS/IBGW (but well before when 10.19 became the "stable" version), "PACEAPI" became the default unless you explicitly disable it in the Global API Configuration screen.
If you experience "hangs" or orders that do not get placed properly without any error messages you might want to review your client code. Make sure that your code handles each and every error callback and, under no circumstance makes calls to sleep() functions that block the calling or all threads in your client. And most importantly, never do anything that blocks the TWS API callback thread.
I also make reqMktData() and reqContractDetails() calls that frequently go well beyond the 50 requests per second limit but I have never had an issue with that. Just to make sure I just re-ran one of my system integration tests that burst requests ContractDetails for 503 S&P 500 stocks:
- It took 41ms to fire off 503 reqContractDetails() calls. That is a peak rate of more than 12,000 requests per second or one request every 82 microseconds
- It then took 10.349 seconds for all 503 responses to come back. That is, in average, one response every 20.5ms or a rate of 49 request/responses pairs per second. I'd say the TWS pacer does a pretty good job.
The architecture of this test is simple:
- There are no sleeps or delays in the code.
- Each reqContractDetails() creates a object that is stored in a list of all outstanding requests.
- Once ContractDetails objects arrive from TWS/IBGW they are forwarded to corresponding with the
(?value) call.
- In case an error callback is received for a request, the corresponding is marked
(?ex)
- The main thread can process the responses as the various s complete (or completeExceptionally) or it can ask to be suspended until all s in the list are complete.
- All programming languages have similar (or even identical) concepts for routing responses to the corresponding requestors.
I'd suggest you make sure your TWS/IBGW does not disable PACEAPI and you trust the built-in pacer. Not only will that take complexity out of your client, but you will immediately take advantage of any request rate limit relaxation (that has been rumored to come in 2025). And traditionally, IBKR has silently relaxed various API related limits over the years.
Hope that helps
´³¨¹°ù²µ±ð²Ô
?
On Fri, Jan 10, 2025 at 08:13 PM, Andy Sanders 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??
|
Re: reqHistoricalTicks() & batching vs. reqTickByTick() vs. reqHistoricalData(), Backtesting vs. Realtime execution
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 identical to recorded reqTickByTick() streams for the same period. Just try it for a day or two next week.
I have no recorded natural gas ticks, but here the trade profile for ESH5 last week from recorded reqTickByTick() data:
- There were 2.5Mio trades last week with a total volume of just shy of 7Mio contracts
- 55% of the trades and 20% of the total volume came from trades with a size of 1
- 90% of the trades had a size of 5 or less while 90% of the total volume came from trades with sizes of 25 or less.
- You see there is a "long tail" ending with a trade of 1,895 contracts (just over $555Mio) where you can find "large" trades
´³¨¹°ù²µ±ð²Ô
?
?
?
?
?
?
?
On Sat, Jan 11, 2025 at 09:38 PM, Brendan Lydon wrote:
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() and check feasibility there. My strategy is similar to another classification machine learning model I wrote for 1 minute OHLCV bars which I used to map a bunch of different features and ran in realtime. That was straight forward, as you can stream reqHistoricalData() in realtime for each new bar update on the minute every minute and feed it through the model to get your prediction on the next candle: up or down, and form a strategy around existing positions that way. With this though, I plan to center my classification model around 'large' orders to answer the same question though: up or down, but I want to pass a new x-vector through my trained model on each 'large' order. Assume its a basic logistic regression binary classification problem, so the x-vector I pass into the model will make a signal every time the large order threshold is met. I will obviously set a threshold for 'large', probably dynamic based on current tick-by-tick volumes, say outside 2 standard deviations for example. I want to avoid using bar like data structures like tick-bars, volume bars, imbalance bars, etc. I said a basic logistic regression binary classification model, but in reality it will be probably end up being a multi-class classification model using an LSTM like architecture with classes like: long, short, do nothing. And pass a multi-dimensional vector packing in all tick data and associated, mapped features between large-orders into the next signal. None of the strategy matters though if the data I use in real time is not as close to the data I back test on. And I am worried that a 'large' order defined by the data I am using for the backtest, collected via reqHistoricalTicks(), will approximate parameters for the features I come up with based on values I may never see in realtime if I then decide to use reqTickByTick() making the backtest obsolete with this current data I have. Collecting enough reqTickByTick() data could potentially take years to have a valid dataset to train on if I started collecting now. I hope that clears up my intentions for the strategy and I appreciate your thoughts.
?
Thank you,
Brendan
|
Re: reqHistoricalTicks() & batching vs. reqTickByTick() vs. reqHistoricalData(), Backtesting vs. Realtime execution
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.
|
Re: reqHistoricalTicks() & batching vs. reqTickByTick() vs. reqHistoricalData(), Backtesting vs. Realtime execution
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() and check feasibility there. My strategy is similar to another classification machine learning model I wrote for 1 minute OHLCV bars which I used to map a bunch of different features and ran in realtime. That was straight forward, as you can stream reqHistoricalData() in realtime for each new bar update on the minute every minute and feed it through the model to get your prediction on the next candle: up or down, and form a strategy around existing positions that way. With this though, I plan to center my classification model around 'large' orders to answer the same question though: up or down, but I want to pass a new x-vector through my trained model on each 'large' order. Assume its a basic logistic regression binary classification problem, so the x-vector I pass into the model will make a signal every time the large order threshold is met. I will obviously set a threshold for 'large', probably dynamic based on current tick-by-tick volumes, say outside 2 standard deviations for example. I want to avoid using bar like data structures like tick-bars, volume bars, imbalance bars, etc. I said a basic logistic regression binary classification model, but in reality it will be probably end up being a multi-class classification model using an LSTM like architecture with classes like: long, short, do nothing. And pass a multi-dimensional vector packing in all tick data and associated, mapped features between large-orders into the next signal. None of the strategy matters though if the data I use in real time is not as close to the data I back test on. And I am worried that a 'large' order defined by the data I am using for the backtest, collected via reqHistoricalTicks(), will approximate parameters for the features I come up with based on values I may never see in realtime if I then decide to use reqTickByTick() making the backtest obsolete with this current data I have. Collecting enough reqTickByTick() data could potentially take years to have a valid dataset to train on if I started collecting now. I hope that clears up my intentions for the strategy and I appreciate your thoughts.
?
Thank you,
Brendan
|
Re: reqHistoricalTicks() & batching vs. reqTickByTick() vs. reqHistoricalData(), Backtesting vs. Realtime execution
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 of data does your strategy really need?
I guess your first step is to define exactly what data your strategy really needs. If it needs size information for every individual trade that happens, only the TickByTick feeds can give you that information. But if cumulative volume over a certain time period is sufficient, candles/bars may work, too. But keep in mind that the only real-time bar feed currently available is the 5-second reqRealTimeBars() and there is no 1 second real-time feed. But you could easily make one from a TickByTick feed yourselves.
Since you specifically mention? 'large "tick" trades', I am going to assume that none of the bar feeds will work for you and that you need to use TickByTick feeds.
Keep in mind, though, that you see only the TRADES (level 1) not the ORDERS (level 3). A single order for, say, 10,000 units, will probably be filled from many smaller trades and likely at several different prices. You will see those individual trades but never one with "size == 10,000". Having said that, you can detect from reqTickByTickData(TRADES) feeds when something out of the ordinary goes on.
?
Back-test with the same data that your live trades gets
Assume that the various data feeds provide different values so you must make sure that you back test with the same (equivalent) data that your live trader would experience. I suggest you make a small client that records next week's reqTickByTickData(TRADES), download the reqHistoricalTicks() next weekend, and compare the results.
For many instruments, reqHistoricalTicks() will provide additional data that is not be part of the real-time reqTickByTickData(TRADES) feed for the same period. Those are generally "non-reportable" trades and can be filtered out by looking at the specialConditions field of the HistoricalTickLast objects. You should be able to convert downloaded reqHistoricalTicks() into feeds that are almost identical to what reqTickByTickData(TRADES) would have provided.
?
Make your trading logic truly TickByTick
Set your trading logic up such that it is not aware of where the data actually comes from.
During a live session you will receive one tick at a time (though possibly hundreds or even thousands of ticks during busy seconds) so that your trading logic would provide an event handler interface such as "onNextTick( TickByTickLast last )" that consumes each individual tick when it arrives. You would wire that event handler up to a reqTickByTickData(TRADES) feed in a live session or, during back testing, feed it one tick at a time from a previously recorded reqTickByTickData(TRADES) file or from a (filtered) reqHistoricalTicks() download.
And when you back-test, you obviously want that to run as quickly as possible and many times faster than real-time. So the "chunked" download behavior of reqHistoricalTicks() does not really matter. BTW, last time I checked IBKR allowed you to request up to 1,000 ticks for each call to reqHistoricalTicks(), though you would always receive data for full seconds so that you occasionally receive more than 1,000 ticks.
?
Time stamps in TickByTick data
Most of IBKR's time stamps still have a resolution of 1 second and that includes TickByTick data (live and historical). But that is generally no issue since the logic consumes one tick at a time anyway. During live feeds you can time stamp the arrival time with a higher resolution time stamp (I use the Java Instant with a precision of 1 nanosecond, but a realistic resolution on my server of 1 microsecond) and get a rough feel for the spacing between trades within the second. For recorded feeds or historical download you just need to make sure that you save the ticks in the order your receive them.
?
I guess I could write an entire book on this topic, but I hope these thoughts help.
´³¨¹°ù²µ±ð²Ô
?
?
?
On Sat, Jan 11, 2025 at 02:11 PM, Brendan Lydon wrote:
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 reqHistoricalTicks() & whatToShow='TRADES' was selected going back to early 2023 for natural gas. In real time, I imagined I would use reqTickByTick() to get the most recent ticks and act accordingly to the strategy. However, I am aware that reqHistoricalTicks() uses a batching algorithm to batch all ticks to each second I believe. Atleast, that's what the timestamp suggests when received from IB. So, because reqTickByTick() is more granular and I do not believe batches to each second, I am concerned any strategy I form will not be reliable in execution because the data will be too granular and you cannot stream reqHistoricalTicks() in realtime I believe like you can with reqHistoricalData(). The main problem, is my strategy revolves a lot around large "tick" trades. So, more granularity means broken up matched orders, in turn large order sightings are not frequent. In practice, should I just be streaming some sort of 1 second bar using reqHistoricalData() as that is really what reqHistoricalTicks() is giving me? Or am I wrong?
?
Thank you.
|
Re: What is the exact limit on number of requests?
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 not remember trying to minimize this interval vigorously because I don't need to).
?
In addition to this my order placing synchronized queue is set to either wait for order submission confirmation from TWS or skipping 20 ms after order submission when confirmation cannot be expected (i.e. for orders with Order.Transmit = false).
?
--
Best,
DS
|
Re: conditional order conditioned on execution of buy order only?
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 that the client side including last mile has no effect on the synchronicity of the price changes I would also deactivate both orders before making the changes and activate them thereafter. This can possibly be implemented via the provided Order.Transmit mechanism though I'm not sure if it offers a way to deactivate both orders momentarily, so my own preference would probably be to set the parent order's good-after-time to a distant future and then remove it again when ready.
?
But it also should be noted that changes to limit orders in the book are likely to cause order cancellation and new submission to the exchange under the hood, so it's probably easier to cancel the orders altogether and submit new ones.
?
--
Best,
DS
|
Re: reqHistoricalTicks() & batching vs. reqTickByTick() vs. reqHistoricalData(), Backtesting vs. Realtime execution
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 my realtime trade execution to match as close as possible to how my backtested data was collected. Any thoughts?
|
reqHistoricalTicks() & batching vs. reqTickByTick() vs. reqHistoricalData(), Backtesting vs. Realtime execution
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 reqHistoricalTicks() & whatToShow='TRADES' was selected going back to early 2023 for natural gas. In real time, I imagined I would use reqTickByTick() to get the most recent ticks and act accordingly to the strategy. However, I am aware that reqHistoricalTicks() uses a batching algorithm to batch all ticks to each second I believe. Atleast, that's what the timestamp suggests when received from IB. So, because reqTickByTick() is more granular and I do not believe batches to each second, I am concerned any strategy I form will not be reliable in execution because the data will be too granular and you cannot stream reqHistoricalTicks() in realtime I believe like you can with reqHistoricalData(). The main problem, is my strategy revolves a lot around large "tick" trades. So, more granularity means broken up matched orders, in turn large order sightings are not frequent. In practice, should I just be streaming some sort of 1 second bar using reqHistoricalData() as that is really what reqHistoricalTicks() is giving me? Or am I wrong?
?
Thank you.
|
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
|
