Re: Level2 data falls behind actual market
You're not using wifi by any chance, are you?
Anyway, if you're ever wondering which end of your system can't keep up I suggest playing with dd progress=status for a few minutes.
Good luck!
|
No realized profit and loss for Forex ?
Hi,
if i execute m_pClient->reqPnLSingle(...) for the forex pairs i get 0.0 as pnl even if there were trades executed with a result different from 0. Why is that ? does this have something to do with virtual FX positions ? If i do exact the same for a stock i can get the correct pnl.
|
Re: Order entry time via the API?
Thanks, I will take a look at the flex reports, although I suspect this data is not available.
I'll report back here if I find anything.
|
Re: Level2 data falls behind actual market
Yes
No need to upgrade, especially this have nothing to do (or not enough) with GPU. It's only CPU based computation. Better invest in SSD than GPU
I guess your testing method (Still unclear to me how you proceed)? is not suited to what you want to check, and as @buddy suggest it, write a dumb CSV and check it later to get confidence.
'rogers'
|
Re: Order entry time via the API?
I don't know how. Generally manual and automated are not very easy to run simultaneously. Trend is to add Manual capabilities UI directly on your automate so that your automate DB can store info
If this is for auditing and not millisecond oriented, maybe take a look at info that would match your desire using
|
Re: Order entry time via the API?
Thanks for the reply.
My application is listening for the openOrder callback, but I was expecting to see an order creation/submit time field on the order itself. For example, my application may not be running when an order is submitted manually via TWS, it is then not possible to find out via the API later what time it was submitted.
|
Re: Pairs trading: Parent vs Child order placement
That is how are supposed to work. All orders in the bracket match the parent order quantity as the as long as the parent order exists. IBKR says:
When you place the bracket order, IBKR adjusts quantities for all attached child orders to match the parent order (desired) quantity. Once the parent order starts filling, IBKR automatically adjusts quantities for all child orders to match the actual filled quantity of the parent until the parent order is considered filled (partially or completely) and becomes inactive.
I say "all child orders" since you are not limited just to a profit taker and stop loss order and you can attach additional child orders to the parent in the bracket. One that comes to mind is a "close position at the end of the session" order that sells the position at some point should neither profit nor loss orders have not triggered yet.
´³¨¹°ù²µ±ð²Ô
On Mon, Aug 14, 2023 at 07:05 AM, HenryE wrote:
Here's a visual representation of the order tree I aimed for:
sell 100 @ $20
? |___ sell 125 @ $25
? |___ buy 75 @ $15?
However, I've encountered an issue. Even though the orders are submitted to TWS and appear as described in the tree, once they are eventually "transmitted" in the UI, all child order quantities get changed to 100 units (the same value as the parent).
Is there a specific setting or option within the TWS or IBKR API that might be causing this change in order quantities? I'm trying to ensure that the child order quantities remain as defined.
|
Re: Pairs trading: Parent vs Child order placement
Thanks for the explanation of the different order types and the example.
Building on your example, I've tried to construct a similar tree of orders by linking parent and child limit orders for the same contract using the parentId attribute:
?ib_order = IBLimitOrder(self.action, self.quantity, limit_price_magnified, orderId=ib.client.getReqId(), transmit=transmit, outsideRth=outsideRth, parentId=parentId)
Here's a visual representation of the order tree I aimed for:
sell 100 @ $20
? |___ sell 125 @ $25
?
? |___ buy 75 @ $15?
However, I've encountered an issue. Even though the orders are submitted to TWS and appear as described in the tree, once they are eventually "transmitted" in the UI, all child order quantities get changed to 100 units (the same value as the parent).
Is there a specific setting or option within the TWS or IBKR API that might be causing this change in order quantities? I'm trying to ensure that the child order quantities remain as defined.
------
Semi-unrelated but it seems like another possible limitation in the TWS API is that you can only attach one hedge order per parent order. At least this appears to be the case via the UI, still need to write a proper code based test case for this.
|
Re: Level2 data falls behind actual market
On Sat, Aug 12, 2023 at 02:01 PM, ebtrader wrote:
My buddy ran it with a laptop that has an Nvidia 2 series GeForce and it
worked fine without falling behind.? I will upgrade my machine and then it
should work.
Not THIS Buddy!
Please, I'm begging you, at least try dumping the data to a file first and watching it with . If you don't have tail, find it... in the WSL or install cygwin.
The test should be easy as pie, don't overthink it, just comment/ifdef out the SQL insert and replace it with a file append. Unless your computer has floppies with a 10Mbit network (i.e. ancient) everything should keep up. Then tune the db as previously suggested.
You haven't mentioned any kind of real-time computation happening on the CPU or GPU so the process is basically all network and disk I/O bound. If you need to upgrade anything it will be the network and/or disk first, and only then the [CG]PU; assuming you want to keep the data.
Be reasonable! With interest rates this high who can afford unnecessary capex?
|
Re: Level2 data falls behind actual market
My buddy ran it with a laptop that has an Nvidia 2 series GeForce and it worked fine without falling behind.? I will upgrade my machine and then it should work.
Outside RTH it stays in sync no issues.? Only during RTH is the issue. Look to me like the Highest Bid and Lowest Ask. They are unrealized transaction.
They are reported in the callbacks, "I am sure of it."
How you compare it is the issue, if you display TWS in // to a SQL SELECT, definitively it's move too fast to be insync, you may even have TWS late to the API, but your DB is most probably the reference, or you should investigate your INSERT timing. (you better bulk it in a separate thread)
If you want to make a visual inspection, don't use the [0] but someplace deeper, like around the 20th row or with 0.25% <> to top, they change less frequently as they are more "fishing" position and any better bid or more aggressive ask may insert above but faster.
Or take a stock that not aggressively traded, low daily volume typically.
Or take a look at it outside RTH, market are way slower.
Or don't use a DB but a memory Map and dump it,
etc ....
Trust the API and dig elsewhere.
|
Re: Having trouble submitting ZT (2 yr treas) futures orders thru API.
On Fri, Aug 11, 2023 at 06:33 PM, Lou Dudka wrote:
Yeah, the 10.19 TWS went slick as snot, probably the easiest upgrade I ever
did!
Sweet.
On Fri, Aug 11, 2023 at 06:33 PM, Lou Dudka wrote:
I've learned to live with the vagaries of XLS
You'll have to let me know the secret. Although, I admit it will probably never sink in for me :-)
|
Re: Order entry time via the API?
What do you call "entry/creation time." ? Is the info you look for available on TWS ?
Isn't the openOrder call back giving you enough as a first proof of existence ?
Also usually people read that
As the sequencing of orders can be an issue.
|
Re: Having trouble submitting ZT (2 yr treas) futures orders thru API.
Hi buddy,
Thanks for the TWSAPI e-mail, I appreciate your concern and interest.? Didn't want to send a private reply to you and get your company upset at you.? Kudos to your new avatar.
Yeah, the 10.19 TWS went slick as snot, probably the easiest upgrade I ever did!
The ZT trades went thru just fine in the new API.? The problem is upgrading my XLS's.
I'm so backleveled with my current API it'd take a ton of work to get my xls/App up to date.? I've touched just about every VBA module the IB supplied in the sample API.? I'm far more interested in trading than writing code ...? I use a separate XLS for each instrument (yeah, I know, I can already hear the naysayers ...) - one of the main reasons being it serves as a database and I have an absolutely phenomenal history of each to run "what-ifs" against.? I'm a retired Head Data Base Admin from a major international car company, so yes, I do understand databases.? Sometimes simpler is better ...? Everything is self-contained and runs like the wind.? I've learned to live with the vagaries of XLS (as Richard has rightfully pointed out on numerous occasions) and it works just fine for me.
I have a work-around for the ZT trades (90% of which DO go thru) so I'm OK.
Thanks, as always,
Lou Dudka
|
Re: Is it possible to place order at 15:59 or 16:00 and get a fill?
If you need to exit at end of day with the highest execution chance and arguably the most liquid price, the best order type to use is MOC (Marketable On Close). These orders pile into the closing auction event that usually gets 5-15% of liquidity for the entire day, i.e. about an hour worth of regular trading packed into a single event.?Additionally MOC orders remove the hassle of tracking the exact time of market close which can be different on certain dates. This will save you a lot of efforts and troubles, which will very likely hit you if you are contemplating placing marketable orders into after-hours trading where poor liquidity can be destructive to any reasonably good trading strategy. Placing regular-hours orders a few minutes or seconds before market close is generally much safer but offers little to no benefits compared to a MOC order. But this all is rather an aspect of strategy than technology, so it's not directly relevant in this discussion group. For a MOC order, use OrderType = "MOC" and Tif = "DAY".
--
Best,
DS
|
Order entry time via the API?
Just started working on an application using the API. My app is listening on the callbacks for reqCompletedOrders and?reqAllOpenOrders
I can see order/contract/status details but I can't find a field for order entry/creation time. I have checked the documentation and can't see it.
Does anybody know how to retrieve this?
Andy
|
Re: Error when requesting 20 years of price data for specific ticker [CHTR]
If I rephrase your concern I understand it as: why different tickers with exactly same exchanges behave differently on historical request ?
I paraphrase here what Jurgen already said:
I agree that CHTR is not an exotic instrument, and I am not familiar enough with constraints that can arise from some 'exchanges' like FOXRIVER or CSFBALGO? or IBEOS etc ...
however the principle in order to fulfill your request is that IB try to fetch data, but doing so IB need access to some 'exchanges' that you are not allowed to get data from. (And maybe you will never be able to access, or finding which exchange is part of the SMART aggregate and induce the failure is too much time consuming)
Worth a try submitting this to IB support to know which exchange was missing in your subscription (if it's a real miss) they may have tools to diagnose that faster than trough API with trial/error.
Somewhere SMART create catch 22 situations for IB, because IB know that there are accurate data available but they can't deliver it for copyright reason, so it is somewhere safer that IB complain about your subscription rather than answering wrong info.
It became your decision to fall back on an exchange part of your subscriptions.
You can reverse the issue and understand it as on CSX or CHRW, IB doesn't need access to specialized exchange to deliver you the data.
Personal opinion
I never use SMART when fetching historical data, because when IB return data:
1- I don't know what I am looking at.
2- if a bar or a price is missing from primary exchange, I better know it in order to anticipate an execution issue, like hiding a lack of liquidity, or ...
I may miss the beauty of SMART and I don't know what TWS is doing for chart, but so far so good.
3- As most of this algo business is working by doing comparisons, it could be better to decide a constant sound reference, related to your algo, even if wrong towards the rest of the world, could be right within the mindset of your algos.
Or quit the opposite and knowing precisely any differences that may exist between exchanges.
|
Re: Level2 data falls behind actual market
Outside RTH it stays in sync no issues.? Only during RTH is the issue.
Look to me like the Highest Bid and Lowest Ask. They are unrealized transaction.
They are reported in the callbacks, "I am sure of it."
How you compare it is the issue, if you display TWS in // to a SQL SELECT, definitively it's move too fast to be insync, you may even have TWS late to the API, but your DB is most probably the reference, or you should investigate your INSERT timing. (you better bulk it in a separate thread)
If you want to make a visual inspection, don't use the [0] but someplace deeper, like around the 20th row or with 0.25% <> to top, they change less frequently as they are more "fishing" position and any better bid or more aggressive ask may insert above but faster.
Or take a stock that not aggressively traded, low daily volume typically.
Or take a look at it outside RTH, market are way slower.
Or don't use a DB but a memory Map and dump it,
etc ....
Trust the API and dig elsewhere.
|
Interesting chain, I trade VX futures daily, Jurgen is correct 5 cents is the min price increment as per CBOE restrictions, the min bid-ask spread is therefore 5 cents.
Some pointed out that the VIX calendar spread has 1 cent min price increment, this is true, but it is also true that the bid-ask spread there tends to be 10 cents +,
so it more economical to buy and sell each future individually, also there is a lot more liquidity, than buying/selling the spread outright.
Is it useful to know that the mini-VIX contract, VXM, does have a 1 cent price variation, tighter spread, and decent liquidity if you are small enough.
Finally, I would echo this comment:
toggle quoted message
Show quoted text
if you're not REALLY sure of what you're doing and the risks involved, stay away from VX futures and all derived products.
|
Re: g++ command for including the proper libraries
Thanks Gordon and Jurgen. I figured out the problem. My mingw64 compiler was using a target architecture of x64, but the TwsSocketClient.dll was built using a x86 or 32-bit architecture. The reason I have chose to go this route is I like using visual studio code rather than visual studio because I find it clunky and I like working from the command line. Makes me feel good about myself. However, all it took in the end was opening up the TestCppClient.sln in Visual Studio and running main.cpp using win32 and magically a command window appeared trying to connect to TWS. It's as if someone recommended that all along...Lol. But, now I think I know the problem for g++, and which library to link. So, I will be installing a mingw32 version with a C++ compiler. I will post the full .bat file I come up that hopefully works based on everyone's recommendations and my own meddling for correctly linking the TwsSocketClient.dll to my project with the proper Client Class inheriting from EWrapper. Hopefully, it could help someone facing the same issues.
Thanks again,
Brendan?
|
Re: Error when requesting 20 years of price data for specific ticker [CHTR]
Great catch from @ds-avatar: the dates are indeed different (so the difference in the last pair of screenshots are not meaningfull. So this morning, I run my code but using ISLAND for CHTR. And it worked on the first trial (without my workaround of opening a chart with share prices for CHTR) - see below. Here is a puzzling part: @´³¨¹°ù²µ±ð²Ô Reinold allerted me to the following: "In general, a smart-routed historical data requests will require subscriptions to all exchanges on which a instrument trades". So I got the "validExchanges" info for the contracts I was using to ask for price data. See below that after each set of price data, there is now a "CONTRACT DETAILS" section. Note that for CHRW and CSX (two other Nasdaq-listed stocks) the "Valid Exchanges" are exactly the same as for CHTR. So not sure why the issue happens only with CHTR (and not the other Nasdaq names in my test list). Tomorrow I will run the code with "SMART"? for CHTR and see if the error happens again and report back. Thank you all for the help so far. 
|
buddy
Rational-IM