Support Board
Support Board
Search Board
Control Panel
View My Posts / Threads
Direct MessagesDate/Time: Mon, 06 May 2024 11:11:43 +0000
Bracket order and OCO order between Lmax and Sierra
View Count: 1626
| [2018-08-28 09:31:48] |
| Fabio - Posts: 111 |
|
Good morning, I would like to know if bracket orders or OCO orders placed through sierra work fine even after shut it down but before get them filled with Lmax broker. Can I place order with brackets or OCO order in Sierra and then close it off before get filled with no problem? or does the platform need to be open? Thanks, F. |
| [2018-08-28 18:34:04] |
| |
|
Yes they will still be working and managed on the server. You just need to make sure these options are enabled: Global Trade Settings Windows: Use Server Side OCO Orders (if supported) (Global Settings >> General Trade Settings >> General) Global Trade Settings Windows: Use Server Side Bracket Orders (if supported) (Global Settings >> General Trade Settings >> General) 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: 2018-08-28 18:35:19
|
| [2018-09-01 12:37:26] |
| gomifromparis - Posts: 244 |
|
This works well with the following limitations : * Since the orders are not considered as attached SL/TP by the LMAX server, it will consume twice the margin, when compared with the web SL/TP orders. * Since the SL/TP are not attached to the trade, you can have side effects. For instance, on a couple occasions, I closed manually my order very near to the SL or TP, and the server didn't have the time to close its own SL/TP before it was executed, and I was left with a naked position in the market. First time it happened it was very unpleasant since it was last trade of the day, I closed it manually and closed Sierra immediately. When I opened it again later in the afternoon I saw I had a naked (red of course) position that was running, it was opened the same time I closed manually my position. Apart from that it works well, however I would feel more confortable if they were on the LMAX server instead of the Sierra server (anything can happen :-)). Unfortunately the LMAX SL/TP is not available on FIX protocol, so it's unlikely to happen... |
| [2018-09-01 14:40:24] |
| |
|
* Since the SL/TP are not attached to the trade, you can have side effects. For instance, on a couple occasions, I closed manually my order very near to the SL or TP, and the server didn't have the time to close its own SL/TP before it was executed, But the timing difference between what LMAX can do and what the Sierra Chart server was able to do is very negligible. Less than a millisecond. We are developing our own exchange functionality which has exchange managed target and stop orders, but this scenario you describe can still happen. And this is in an environment where execution times are down to the microsecond/nanosecond level within the same process. If the target or stop order has filled at the time that those Target and Stop orders are being canceled and an offsetting order has been received, then this will result in a new position. We think really the only way this could be solved is with an order instruction like BitMex has where it is a reduce only order. But it is still possible, simply due to the multithreaded nature of the exchange functionality, and the fact that order matching is done with extreme performance in a separate thread, without regard to position quantities which are tracked in another thread, that a reduce only instruction is not always going to work perfect and could from the perception of the end user, look like it did not work. In order for order matching to be extremely fast, it does not involve margin, risk, or positions. All of that is handled on other threads before and after the executions. And we do not think the LMAX disruptor functionality is any different. How could it be. Have you ever thought about how order matching works. Basically you have a queue orders coming in on one thread and from a network and they have to go through risk and margin checks. And then you have another thread which is going to match those orders. If your target or stop order has been filled and then you have got another order coming in to offset the original position, you are going to simply have a new opposite position. 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: 2018-09-01 14:56:41
|
| [2018-09-01 14:58:40] |
| gomifromparis - Posts: 244 |
|
LMAX is like Bitmex, there is a "reduce only order", see "how do I close a postion via API" in the doc https://www.lmax.com/pdf/LMAX-Global-API-FAQs.pdf "You can do this by constructing a “ClosingOrderSpecification”. This allows you to place a market order in the opposite direction of an existing position, which closes out a given quantity. " This prevents you from being able to open opposite orders on a close. However it doesn't seem to be available in FIX. This it the very reason I started working on an API DTC connector. Date Time Of Last Edit: 2018-09-01 15:00:48
|
| [2018-09-01 15:00:47] |
| |
|
But we still do not agree, that this can work perfect. When you logically think through the process of order execution and understanding that the LMAX disruptor does nothing more than order matching, and all other checks are external to it and on other threads or processes, you can still face the same scenario. The LMAX disruptor does not even use locks and is multithreaded and this is what makes it high-performance. See our prior post. It was updated before we saw this latest post of yours. The very fact that positions are not even provided over FIX quite clearly implies that the LMAX core order matching does not have any knowledge of positions. The LMAX API you are referring to is built on top of the LMAX order matching and probably also uses FIX. This is what we were told by them years ago. 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: 2018-09-01 15:06:24
|
| [2018-09-01 15:07:26] |
| gomifromparis - Posts: 244 |
|
no it's not the same functionality, and the API specifically allows contingent orders which will use some kind of order tracking with the specification id. I'll try to provide some logs
|
 lamxinfo.png / V - Attached On 2018-09-01 15:07:18 UTC - Size: 35.29 KB - 293 views |
| [2018-09-01 15:10:27] |
| |
|
no it's not the same functionality, We do not know what you mean by this. I'll try to provide some logs What would the logs prove?We do not agree you can avoid the scenario. Having a deep understanding of how all of this works, it would be impossible to avoid. When processing orders out of a queue, and when not using any synchronization, and checks for positions at the time of execution, which would create significant overhead, you can still face the same scenario you describe in your first post. Ask a LMAX software engineer and they will confirm this. Unless they were to submit another order to offset the new position. Do they do that? That really is the only solution, to submit another order to offset a new resulting position at the time you are performing a cancel and flatten operation. 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: 2018-09-01 15:13:10
|
| [2018-09-01 15:19:48] |
| |
|
If you were to start to do everything totally perfect like you are describing, doing position checks, margin checks and risk checks, at every order match, then you just create massive overhead and then you would end up with an overload scenario and start dropping orders like BitMex does. And this is not thinking from the realm of theoretical. We know because we have developed exchange functionality. We will be putting it out as a test environment sometime soon. One thing we are working on now, is working on the storage method for the orders in order to get the absolute lowest possible timing for order matching. 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: 2018-09-01 15:21:16
|
| [2018-09-01 15:35:51] |
| |
|
This is a good discussion and what we are going to do is add to the DTC protocol a reduce only instruction which will be submitted with flatten orders. But we are really not sure how this would help with LMAX because the Sierra Chart process which is handling the order routing to LMAX does not know anything about positions so in the end the scenario can still happen. And the very fact that there is no position reporting on LMAX FIX does indicate that the LMAX core foundation order matching, is nothing more than pure order matching and runs no safety checks like you are describing. This is is all external and built on top of it. And can still run into the original scenario. 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 |
| [2018-09-01 15:47:27] |
| gomifromparis - Posts: 244 |
|
There is no margin and risk checking to do with contingency orders. The margin is checked when you open the order and that's it. If you get a "close position" order, there is no check to do either. When you use the API, you create an instruction Id representing the order. On this instruction id, you can attach a stop and a target, that will run OCO You can also ask to close this specific position using the given instruction id. So the order is fully followed from open to close. Probably with some syncronisation... It's the same using IG API :-) So dunno all the funkiness about the Disruptor, but there is definitly a layer over it providing precise order management, but only available through the API. The only thing preventing to use this completely in Sierra is that the "flatten orders" sends unspecifc market orders, but I'm seeing you'll be modifying this, so thanks a lot ! |
| [2018-09-01 16:02:06] |
| |
|
but there is definitly a layer over it providing precise order management, We do not think this is possible with our understanding of how everything works on the LMAX side. It could not be "precise". We think that is a false perception. We have given this some thought and we do not see how it could always work perfectly.You are looking at it from the perspective of documentation and not going into the practical lower level working details. Risk and margin are not relevant, yes that is true, but position updating is. That is all part of the process. The tracking of a position is completely separate to the LMAX order matching. And going back to the original scenario, what you described is sending an offsetting position around the same time that one of the Stop or Target orders is executing. FIX is most direct connection as we understand to the core LMAX order matching. This is why we understand there is no position reporting. These other APIs are other seperate systems and we do not see how there can be perfect synchronization between them. There is always going to be room for imperfections. 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: 2018-09-01 16:57:02
|
| [2018-09-01 16:21:22] |
| gomifromparis - Posts: 244 |
|
We'll see (maybe) how it works, I asked LMAX support.
|
| [2018-09-01 19:22:20] |
| |
|
Yes maybe. We are quite confident with what we say, and we do not believe that whatever LMAX support says can be completely trusted. Support will not know. Only the engineer who understands all of this stuff in depth will. The best that we can do from our side, is reduce latency. And that is what we have been working on and we will do this further. 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 |
| [2018-09-02 09:11:32] |
| gomifromparis - Posts: 244 |
|
Who knows, maybe they're like Sierra and support guys are also in the engineering team. :-) Yes, you can reduce latency in the platform, but can't reduce physical distance, so if you're at 200 ms of the Exchange, there's still a possibility that you flatten a position already closed 200ms before by the target profit, creating a naked position. Also, I had a quick look on the Disruptor, its speed is not about not using locks, it's about not using java locks. They use internal CPU registers as locks and atomic CPU instructions see http://lmax-exchange.github.io/disruptor/files/Disruptor-1.0.pdf Finally, it seems there is already a flag in DTC to indicate the close of a position, it's OpenOrClose. I think I did some tests using it but if I recall it seemed to not be set by Sierra. So I had to do my own flagging (if current position long and we get a short, we're actually trying to close a position.) Having the flag set by Sierra in a sure manner would be helpful. Thanks Date Time Of Last Edit: 2018-09-02 10:44:39
|
| [2018-09-03 03:27:57] |
| |
|
We have been thinking about this and actually we do realize there is currently a solution to this type of scenario where a Flatten Position order executes at the same time as an Attached Order resulting in an opposite position. You just need to enable this option which will avoid this: Global Trade Settings Windows: Hold Market Order Until Pending Cancel Orders Are Confirmed (Global Settings >> General Trade Settings >> General) 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: 2018-09-03 03:28:22
|
| [2018-09-03 07:58:23] |
| gomifromparis - Posts: 244 |
|
Ok nice, yes it will solve the issue, at the expense of a little latency on the order. Can you confirm that SierraChart does(or will ?) set correctly the OpenOrClose field on the DTC order message ? |
| [2018-09-03 08:08:40] |
| |
|
Additionally after canceling the Attached Orders, if there no longer is a Position the market order is just canceled which it would need to be in order to accomplish the intended objective. So it is a very safe implementation. The documentation has been updated to explain this. Can you confirm that SierraChart does(or will ?) set correctly the OpenOrClose field on the DTC order message ? 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: 2018-09-03 20:46:27
|
| [2018-09-04 10:02:05] |
| gomifromparis - Posts: 244 |
|
FYI here's the information from LMAX support In the scenario below, there is a possibility that both close instruction and contingent order to fill resulting in a position in the opposite direction but the time between the two orders has to be very small. What you can avoid to stop this from happening is cancel the contingent stop or target and then send the instruction to close that order. |
| [2018-09-04 10:21:21] |
| |
|
Yes so we were right. But the interesting thing is, we later realized that there is a solution to this and that is what they describe. But they have not implemented this on their server. We can implement this on the server side but being it is already supported on the client-side, we will just stay with that as well considering our heavy programming load.
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: 2018-09-04 10:22:08
|
To post a message in this thread, you need to log in with your Sierra Chart account: