Local stops seem slow to execute the actual sell/buy order
lazrfocus opened this issue · 2 comments
When a local stop is executed, there seems to be a 1-2 second delay before the sell order is actually triggered.
It appears as though Orko takes some time to process and clear the first part of the stop job (ie: stop was hit) out;. Then, after some delay, a new local order is created as a new job and finally executed moments later.
This results in delayed order execution which could significantly reduce profits or make a strategy obsolete.
This becomes clear when using trailing stops, or OCO with trailing, which you are unable to place on an exchange.
The time between job activation and actual order execution should be minimized and optimized as much as possible.
I will try to provide more information as I run into the bug again in the future.
Desktop (please complete the following information):
- OS: Ubuntu 19.04 (running in a VM)
- Browser: Firefox
- Version 0.14.2-SNAPSHOT
Agreed, this is an issue. To some degree, it's unavoidable to get some slippage, but:
- There's some asynchrony in the way the order is submitted which could be eliminated (I think this is the main issue and easily solved)
- #360 - At periods of high volume, I've seen Orko fall a bit behind processing all the the updates, particularly on slow VMs. I'm slowly working through pain points (they're mostly from XChange or xchange-stream).
What I actually want to do, which completely sidesteps both the above issues, is #152 - to change the way OCOs and other "soft" orders are processed so that Orko always maintains at least one limit order or stop on the exchange itself. If, say, I have a stop at 100 and a sell at 300, if the price is 199, Orko would maintain the stop. If the price jumped to 201, Orko would cancel the stop and replace it with the limit order. If the price dropped back down under 200, Orko would cancel the limit order and place the stop. This sort of logic would apply equally to more complex orders.
The problem with this is that if Orko is killed or crashes after placing an order but after recording the order id placed, it would lose track of the active order. The basic code is easy, but solving that problem is hard (except on Binance, which provides a solution).
See #152 for the full solution described above.
In the meantime maybe we can just resolve the first point.