Support Board
Date/Time: Sun, 22 Dec 2024 11:25:01 +0000
SC via Interactive Brokers not correctly setting OCO orders - important!
View Count: 5978
| [2015-05-01 18:30:24] |
| |
|
Could SC please have a look and tell me why IB TWS is getting what appears to be a modify order from SC (highlighted in RED)
As we indicated earlier in this thread, you need to look at the Trade Activity Log and you will see all order modifications logged there. Here are instructions:https://www.sierrachart.com/index.php?page=doc/doc_TradeActivityLog.php#ViewingHistoricalTA The reason for the order modification will be stated in the Order Action Source field. So what is the reason for the order modification? Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing Date Time Of Last Edit: 2015-05-01 18:35:48
|
| [2015-05-02 14:34:43] |
| MotoMoto - Posts: 47 |
|
apologies, I completely forgot to add the extra sheet which shows the SC trade activity log. It looks to me that the modify modifies from Qty 2 down to Qty 1, however there is no adjustment back up to Qty 2 when the total quantity is filled. Somewhere along the line, IB and SC are dropping and then not picking up that there is a live Qty of 2 contracts and that the attached bracket orders are not updated for this. Thanks. Date Time Of Last Edit: 2015-05-02 14:37:27
|
 trade issue 29-04-205-external.xlsx - Attached On 2015-05-02 14:32:23 UTC - Size: 27.35 KB - 750 views |
| [2015-05-02 20:48:04] |
| |
|
Now we understand what is going on in this most recently reported case. Originally, Sierra Chart would never modify a server-side bracket order set after it is initially sent, unless the user were to manually modify one of the orders or a trailing stop order needs to be adjusted. At some point, based upon a user request, we were asked to maintain the same offset for the Attached orders that they originally had to the parent order. This happens if Global Settings >> General Trade Settings >> Adjust Attached Orders to Maintain Same Offset on Parent Fill. So Sierra Chart will modify the Attached Order prices and use the existing quantity of those orders when sending the order modification to TWS. Before the order modification Interactive Brokers indicated the order quantity of the orders is 1: Order 14:09.0 CL-201506-NYMEX IB open order update 18819 498 Limit 1 Buy 58.12 Open Close 18818 Order 14:09.0 CL-201506-NYMEX IB open order update 18820 499 Stop 1 Buy 58.72 Open Close 18818 Possibly because there was a partial order fill of the parent before? We cannot see that from the Trade Activity Log because you are not showing the fills, only the order updates. You need to select All Activity. When the bracket order server-side managed, this will no longer apply in the next release: Global Settings >> General Trade Settings >> Adjust Attached Orders to Maintain Same Offset on Parent Fill. This is a good example of the consequence of us being too accommodating to user requests. After having said all of this, we did indicate in post #18 above, that if Sierra Chart is modifying those orders, you will see the order going to Pending Modify state. So as we said, you do have the information in front of you as to exactly what is happening. Also, this does reveal that even a trailing stop order can lead to this problem. So when you are using server side bracket orders, you cannot use trailing stops because that can trigger the problem as well. So we do acknowledge, that what we said above previously that once the bracket order set is sent, Sierra Chart will not modify those orders unless the user modifies them or a trailing stop order modifies them, is not correct if the option described above, is enabled. However, it is not that Sierra Chart had made any mistake with the quantity, it is just simply a complex interaction which occurs which has no solution other than the fact that a client connected to TWS really cannot modify bracket orders, without running the possibility of a scenario like this occurring under some conditions. Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing Date Time Of Last Edit: 2015-05-03 00:32:06
|
| [2015-05-03 07:11:52] |
| |
|
We have been contemplating this problem and one way or another we will find a solution to it. We will run a test, where when the order quantity is not changing, it will not be specified on the order modification when sent to IB Trader Workstation. If this solves it, then great then it is done and there will not be a further problem. If there is a requirement for the order quantity, then we will contact Interactive Brokers and request when the order quantity is zero or an empty string, then this means the order quantity needs to remain the same. We will do our best to convince them that this is a critical enhancement. So at this point, we are taking full responsibility to find a solution to this. Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing |
| [2015-05-03 08:20:41] |
| JRA - Posts: 97 |
|
So, in plain English if I use IB should I turn this future OFF? Global Settings >> General Trade Settings >> Adjust Attached Orders to Maintain Same Offset on Parent Fill Date Time Of Last Edit: 2015-05-03 08:20:51
|
| [2015-05-03 09:28:30] |
| |
|
Yes, however only if using server side bracket orders. And also avoid using trailing stop orders as Attached Orders with Interactive Brokers.
Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing |
| [2015-05-03 13:42:19] |
| MotoMoto - Posts: 47 |
|
Hi thank you for looking into this as it is clearly an issue we hope can be resolved. (Sorry for missing the subtleties of tracking the audit trail, I have never had to bother and sometimes miss the extra details in SC) I have attached the spreadsheet with what I hope shows the extra detail in a 3rd sheet, and will refer to its columns. To me it seems that while you have accommodated another users request to maintain the same offset which actually makes sense, this is about quantity and it is a separate issue to any offset amounts....and it would also appear that this is an issue that has little to do with the trailing of the order as the quantity miss match occurs before any trailing starts. It appears to be a miss match because as I initially suspected the order is filled in two parts (in this example it is at the same price, but in other examples there may be some slippage)and after the 2nd execution the attached orders are not updated based on what the open live quantity is (spreadsheet Col Q). Which is also why its hard to replicate occasionally in live trading and not in SIM. It appears that the quantity to use for any pending or modified orders is reading the wrong (or maybe best to say 'outdated/old') quantity. In the detailed spreadsheet this appears to be happening at ROW 20 and below. example: why is Row 16 showing 2 contracts in the Quantity col (H) when immediately afterward the 2nd executed fill it drops to 1, but the actual open quantity has increased.I can only assume its because its reading the I get that in post #27 "So Sierra Chart will modify the Attached Order prices and use the existing quantity of those orders when sending the order modification to TWS." but shouldn't the quantity be based on what the actual live quantity is (Col Q) and NOT what was the previous existing quantity to update because of these partial fills that can lead to this situation? Maybe when Col Q is =0 then use col H, but when Col Q is <> 0, then this quantity in Col Q is used.... Otherwise, I really appreciate the efforts to solve this problem. Thanks Date Time Of Last Edit: 2015-05-03 17:15:28
|
| trade issue 29-04-205-external.xlsx - Attached On 2015-05-03 13:06:25 UTC - Size: 31.35 KB - 608 views |
| [2015-05-03 20:22:42] |
| i960 - Posts: 360 |
|
When the order is filled TWS communicates to the client the fill and quantity, correct? So assuming it does that and adjust offset is also used then adjust offset simply does an adjustment for only the quantity of the order that was filled and the remainder of the order remains. I don't get what the problem is here. The client has an idea of what the quantity is and the "server" (in this case TWS) communicates to the client what was capable of being filled. It never guaranteed that an entire order could be filled so attach or not shouldn't matter. The client should simply not assume the entire order was filled when modifying the existing order. If you're doing something client side like adjusting orders then you must ensure that all assumptions carried out are true. That has nothing to do with over accomidating user requests at all. It's basic client/server state management. IMO the code is trying to get away with doing as little as possible here when it quite simply cannot do that if it wants to be accurate. I don't see how this is a difficult programming exefcise. Partial fill? Then partially adjust. |
| [2015-05-03 21:27:17] |
| |
|
In response to post #31 and #32, it was Interactive Brokers which set the quantity of the Attached Orders to 1 due to the partial fill. Sierra Chart did not do this. You can see that happen at rows 10 and 11 in the spreadsheet attached to post 31. example: why is Row 16 showing 2 contracts in the Quantity col (H) when immediately afterward the 2nd executed fill it drops to 1, but the actual open quantity has increased.I can only assume its because its reading the Never in 1,000,000 years would we ever do something like this: but shouldn't the quantity be based on what the actual live quantity is (Col Q) and NOT what was the previous existing quantity to update because of these partial fills that can lead to this situation? There is no consistent and definitive association between an order quantity and the Position quantity. And besides, at the time Sierra Chart modified the order the quantity was 1 both for the position and for the Attached Orders.Maybe when Col Q is =0 then use col H, but when Col Q is <> 0, then this quantity in Col Q is used.... I960, we are not going to debate this with you. We understand the nature of the problem and it cannot be solved unless IB allows the modification of the price of an order without specifying its quantity. And when using trailing stop orders, there is also a risk this problem will occur. The quantity of an order can change on the IB side and while that new quantity is being sent across the wire, Sierra Chart is not aware of it, and when SC makes an order modification, it is going to use the quantity that it is last aware of. Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing Date Time Of Last Edit: 2015-05-03 21:30:23
|
| [2015-05-03 21:45:31] |
| i960 - Posts: 360 |
|
I960, we are not going to debate this with you. We understand the nature of the problem and it cannot be solved unless IB allows the modification of the price of an order without specifying its quantity. And when using trailing stop orders, there is also a risk this problem will occur. The quantity of an order can change on the IB side and while that new quantity is being sent across the wire, Sierra Chart is not aware of it, and when SC makes an order modification, it is going to use the quantity that it is last aware of.
It can be solved because ButtonTrader already handles this situation without issue. Do not ever claim something "cannot be solved" unless you're absolutely sure it's technically impossible to do. The quantity of an order can change on the IB side and while that new quantity is being sent across the wire, Sierra Chart is not aware of it, and when SC makes an order modification, it is going to use the quantity that it is last aware of.
And that's your problem. We seem to have a common trend here with SC assuming something and not being defensive against real world race condition type situations. When you get the new quantity sent from IB, you've got additional information to correct the modification that just used stale data. It's a standard split-brain scenario. |
| [2015-05-03 22:37:43] |
| |
|
When you get the new quantity sent from IB, you've got additional information to correct the modification that just used stale data. For so many reasons, we would never engage in this kind of questionable and unreliable programming which involves making assumptions. You are welcome to do that on your side. We will not get involved with it. You are most welcome to use another program if you see fit for your own needs.Also, the kind of problem described in this thread will not happen if Global Settings >>Global Trade Settings >> Use Server-Side OCO and Bracket Orders is disabled which means that Sierra Chart can handle partial fills properly with bracket orders. Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing Date Time Of Last Edit: 2015-05-03 22:39:21
|
| [2015-05-03 22:49:40] |
| i960 - Posts: 360 |
|
So what you're saying is that the client being overly defensive against a potential race condition is unreliable? Absolutely amazing. Let's review again so somehow the logic can sink in: 1. Order partially filled. 2. Client sends modify for fill offset. (race condition here) 3. In parallel TWS sends new quantity across wire. (race condition here) 4. SC does nothing to correct the situation that it just created by modifying attached order to match fill offset even though TWS just gave it additional information from which to correct it. And somehow you classify defensiveness for that self-created situation as "unreliable" because it involves actually writing more code to be defensive against a situation you already know you have to be aware of in the first place. On top of that, the recommendation is basically "turn off feature that creates problem" rather than fix said feature that creates problem. What you are avoiding here is the reality that your current code *is already making assumptions*. It's entirely riddled with assumptive behavior and when assumptions are broken you're quite quick to blame the other side. Date Time Of Last Edit: 2015-05-03 22:51:54
|
| [2015-05-03 23:14:18] |
| |
|
We are no longer going to engage in this discussion. We do not agree with you and we will leave it at that. And you are welcome to use another program. Our position will not change and we will solve this problem properly as we previously indicated.
Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing Date Time Of Last Edit: 2015-05-03 23:14:43
|
| [2015-05-04 06:36:44] |
| phaedonk - Posts: 352 |
|
I believe what you are describing is related with the problems I am still facing every single day. I mentioned them in the thread IB advisor account- when parent is filled child orders change quantity (SC 1215) . Please confirm. I also had "Adjust Attached Orders to Maintain Same Offset on Parent Fill" enabled I was certain that it was IB's fault. IB has responded that they see nothing wrong on their side and no such mentions from other users. |
| [2015-05-04 10:23:43] |
| MotoMoto - Posts: 47 |
|
Hi, just for clarity in the spreadsheet- in Col D those rows with "IB open order update" or "IB Order Fill (execution)" is the information sent from IB to SC and the other rows are information sent from SC to IB? If so... I get that IB is responding with what is actually happening and that the partial fill means that IB are saying there is only 1 contract to update in the attached child orders. rows 10 and 11.....and then in later rows it seems clear that the actual quantity has increased and yet IB has not updated this information that it is sending back to SC (rows 20,21,22). If this is the case then IB is not updating and sending the correct live quantity back to SC. IB is using the old/unmodified quantity. If this is the case IB need to fix this problem to match the actual quantity, and which is why if SC does modifiy the quantity it is based on this incorrect number supplied by IB. //////////////// However, if I am reading this correctly....to get around this... If IB handles the attached orders and the "Use Server side OCO and Bracket Orders (if supported)" is checked, then IB is sending back the wrong info, and SC is merely responding to this. In other words this is an IB problem. If SC handles the attached orders and the "Use Server side OCO and Bracket Orders (if supported)" is NOT checked, then SC will pick up the correct quantities and make sure they match? or does this assume everything has been filled and still picks up the order quantity and not necessarily the position quantity. when you say... There is no consistent and definitive association between an order quantity and the Position quantity. And besides, at the time Sierra Chart modified the order the quantity was 1 both for the position and for the Attached Orders.
I agree with you, in the real world of trading I would only ever want attached orders to represent first and foremost the quantities of my open position quantity, so if SC can read this and modify this shouldnt this be the default check which is what I was asking to ensure happens. If SC is only modifying orders without checking actual open positions then this could also cause problems. Can i confirm that if SC handles the OCO orders then it will match the actual position quantities, and not the order quantities? Thanks. |
| [2015-05-06 03:03:15] |
| |
|
Hi, just for clarity in the spreadsheet- in Col D those rows with "IB open order update" or "IB Order Fill (execution)" is the information sent from IB to SC and the other rows are information sent from SC to IB? Those Order Action Sources indicate order updates from the Interactive Brokers side to SC. I get that IB is responding with what is actually happening and that the partial fill means that IB are saying there is only 1 contract to update in the attached child orders. Yes.If SC handles the attached orders and the "Use Server side OCO and Bracket Orders (if supported)" is NOT checked, then SC will pick up the correct quantities and make sure they match? Yes.Can i confirm that if SC handles the OCO orders then it will match the actual position quantities, and not the order quantities? The problem described in this thread, is not the fault of Interactive Brokers or Sierra Chart. It takes a coordinated effort between both of us to resolve it. We have contacted Interactive Brokers for the proper solution. You will see that in the DTC Protocol, it is possible to modify an order but leave the quantity at 0 which means that the server must keep the quantity at its current quantity whatever it is: http://www.sierrachart.com/index.php?page=doc/doc_DTCMessageDocumentation.php#Messages-CANCEL_REPLACE_ORDER DTC is a very thoughtfully designed protocol. This is what Interactive Brokers should support. Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing Date Time Of Last Edit: 2015-05-06 03:04:45
|
| [2015-05-06 03:08:27] |
| |
|
I believe what you are describing is related with the problems I am still facing every single day. I mentioned them in the thread IB advisor account- when parent is filled child orders change quantity (SC 1215) . Please confirm.
I also had "Adjust Attached Orders to Maintain Same Offset on Parent Fill" enabled Yes it is. Uncheck Adjust Attached Orders to Maintain Same Offset on Parent Fill. We were mistaken about Sierra Chart not touching the order quantities. Indirectly it does with this option enabled and with trailing stop orders. Sierra Chart is not modifying the quantity but uses the quantity last reported from IB, which could be an old quantity as a parent order is filling. Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing Date Time Of Last Edit: 2015-05-06 03:09:15
|
| [2015-08-06 11:25:09] |
| CarlRostron - Posts: 80 |
|
It appears most users who do use Server Side OCO orders do so because they don't want to be reliant upon having their PC's and Laptops (running SC's) switched on 24/7 and the risk of their internet connection being lost where orders are held on their SC client. (I am assuming these orders are held locally on their machine and within their SC application and aren't held on a SC Server anywhere?) This thread highlights the issues SC Engineers face (and understandably so) with other platforms outside of their control. The best way to deal with orders from a SC perspective is clearly when they are all self contained within SC's itself so that SC Engineers have full control of maintaining the code to deal with any problem situations that arise. What is striking to me is the option for an additional product or service SC could offer - that being your own Server Side database of orders for all of your subscribed customers. You would hold these Orders so that users could switch off their machines safe in the knowledge that SC will manage them properly, and they will not be 'Lost' when they turn off their machine, lose connectivity etc You would route them though to the respective Broker in real-time or however is the most appropriate. Wouldn't this be another great addition to the SC platform? (Sorry if this is how it already works but it wouldn't appear so from this thread?) I guess what I am saying is, if I put an order in on my SC platform with OCO server side orders Disabled, and turned off my machine would those OCO orders be executed if in the real world price did hit an order level? Why not SC's hold them on your server and route them through to the broker as necessary when price touches one of these price levels. This is just an idea and probably one you have already considered. (Sorry if I have gotten this completely wrong and you can already do this..?) Great job guys. |
| [2015-08-06 18:00:30] |
| |
|
(I am assuming these orders are held locally on their machine and within their SC application and aren't held on a SC Server anywhere?)
YesWhy not SC's hold them on your server and route them through to the broker as necessary when price touches one of these price levels. This is not possible because Sierra Chart does not have access to a user's trading account.
Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing |
| [2015-08-06 20:31:47] |
| i960 - Posts: 360 |
|
I guess what I am saying is, if I put an order in on my SC platform with OCO server side orders Disabled, and turned off my machine would those OCO orders be executed if in the real world price did hit an order level? Why not SC's hold them on your server and route them through to the broker as necessary when price touches one of these price levels.
Here's what I would personally recommend: If you're not going to be able to be around to watch the market when the orders are live, do not disable OCO server side orders - ever. If your broker doesn't support that, find another broker. With regard to SC hosting a service - it would be completely non-trivial. For one, they would have to be monitoring all prices in real time, for all accounts using this, and then instantaneously update the orders on the broker side. The resource requirements woudn't be small. This is why it is something that broker software typically does (e.g. TWS, or server-side based orders with thinkorswim) and not something that a charting/trading platform usually takes on. |
| [2015-08-06 20:43:38] |
| CarlRostron - Posts: 80 |
|
Yes I had a feeling it wouldn't be an easy thing to do... But it would be quite an incredible solution if one could be found 'reasonably'
|
| [2015-08-06 22:13:49] |
| i960 - Posts: 360 |
|
The thing is, solutions like that eventually end up fragmented and hackish - because they require an external provider to keep in sync with services they don't necessarily control. The better thing is for all brokers to be natively supporting server side orders no matter OCO, or whatever. It's certain brokers subpar implementations of things that place us here in the first place.. IB is actually pretty good server side wise, TDA as well.
|
To post a message in this thread, you need to log in with your Sierra Chart account: