Acceptance of SL/TP orders - page 2

New comment
 
This information should be sent out to all the MT mega-HFTs, just kidding)) The cost of cheapness is this.
 
fxsaber:

It has been repeatedly stated in another thread that even the Terminal slows down from a huge number of factors. As a consequence, a much more complex Trading Server is bound to slow down even more. I still hope that algorithmic optimisation is still possible. Even a 5 ms lag is already very bad. What to say about hundreds of milliseconds.

What about the demo accounts is not very interesting (I can debug any plugins there, test new hardware, etc.).

And I've found max 17 ms on live accounts (I'm not saying it is not long, it just can't be compared with 30 seconds).

Hence the suspicion of a cascading server setup.

 
Andrey Khatimlianskii:

That on demo is not very interesting (you can debug any plugins there, test new hardware, ...).

And on live accounts I found maximum 17 ms (I'm not saying it's not enough, it just doesn't compare with 30 seconds).

Unfortunately, they didn't show how many orders they checked.

Forum on trading, automated trading systems and testing trading strategies

Acceptance of SL/TP orders

fxsaber, 2020.11.25 01:23

Total Orders (from 2020.11.01 00:00:00) = 21725, calculated = 10465
Calculation time = 00:04:33.609, Performance = 38.0 orders/sec.

Hence the suspicion of a cascading server setup.

The broker confirmed the problem and managed to find and fix it (will be available after the weekend). But it's hard to say if it was due to MT5.


But throwing stones in the direction of MT5 can definitely be done by this situation.

Forum on trading, automated trading systems and strategy testing

Acceptance of SL/TP orders

fxsaber, 2020.11.25 00:47

I don't know, I was trying to get my broker to release my order, but I was falling in love with the situation I was in when I traded on the Terminal which is on the same machine where the Trade Server is installed. I.e. with a very low ping and a single trading account for the Trading Server.



Terminal and Server are on the same machine. Zero load. A fresh take got such an alert.

Accepted Tick 2020.11.25 16:05:11.522 10.15469 10.15668
Accepted Length = 4 ms.
Order 212 ORDER_TYPE_SELL EURSEK 2020.11.25 16:05:11.526 10.15462 ORDER_REASON_TP ORDER_STATE_FILLED


Server log.

2020.11.25 16:05:11.526    '': take profit triggered #168 buy 0.01 EURSEK 10.19022 tp: 10.15462, activation price 10.15469 [#212 sell 0.01 EURSEK at 10.15462][10.15469 / 10.15668]


Accept-tick on the server.


Full script data confirmation that there is a problem. Inside the server at zero load there was a lag of 4ms.

 
Andrei Trukhanovich:

another brain blast from fxsaber.

It feels especially bad when you realise how much time you've wasted. And that no one will do it for you.
 

It really seems to be a problem on the server. This is a demo MT5 account

 2020.11 . 25 16 : 58 : 07.787 OrderCheck (USDJPY,H1)  Total Orders (from 2020.01 . 01 00 : 00 : 00 ) = 5417 , calculated = 755
 2020.11 . 25 16 : 58 : 07.787 OrderCheck (USDJPY,H1)  Calculation time = 00 : 00 : 14.656 , Performance = 51.0 orders/sec.
 2020.11 . 25 16 : 58 : 07.787 OrderCheck (USDJPY,H1)  
 2020.11 . 25 16 : 58 : 07.787 OrderCheck (USDJPY,H1)  ServerName: RannForex-Server
 2020.11 . 25 16 : 58 : 07.787 OrderCheck (USDJPY,H1)  
 2020.11 . 25 16 : 58 : 07.798 OrderCheck (USDJPY,H1)  Last Tick 2020.11 . 23 19 : 59 : 30.634 104.341 104.341
 2020.11 . 25 16 : 58 : 07.798 OrderCheck (USDJPY,H1)  Accepted Tick 2020.11 . 23 19 : 58 : 57.044 104.336 104.336
 2020.11 . 25 16 : 58 : 07.798 OrderCheck (USDJPY,H1)  Accepted Length = 33592  ms.
 2020.11 . 25 16 : 58 : 07.798 OrderCheck (USDJPY,H1)  Order 1747932 ORDER_TYPE_SELL USDJPY 2020.11 . 23 19 : 59 : 30.636 104.336 ORDER_REASON_TP ORDER_STATE_FILLED 2020.11 . 23 19 : 59 : 30.658 , Position 1747924 created 2020.11 . 23 19 : 58 : 35.556 , StopLevel = 0
 2020.11 . 25 16 : 58 : 07.798 OrderCheck (USDJPY,H1)  
 2020.11 . 25 16 : 58 : 07.799 OrderCheck (USDJPY,H1)  Orders ( 3 ) before 1747932 with PositionID = 1747924 :
 2020.11 . 25 16 : 58 : 07.799 OrderCheck (USDJPY,H1)  ------------------------
 2020.11 . 25 16 : 58 : 07.799 OrderCheck (USDJPY,H1)  Checked Orders = 0

On a real account with the same broker the script returns zero results. There are over 3000 transactions on the account.

 
Enrique Dangeroux:

On a real account at the same broker the script returns zero results. There are more than 3,000 transactions in the account.

This is suspicious. I haven't found any lag anywhere on my accounts.

 

I'm not sure if it's related. But I get a lot of them. 

2020.11.25 16:52:52.992 Trades  '92810': failed modify #1758569 sell 0.02 USDJPY sl: 0.000, tp: 104.293 -> sl: 0.000, tp: 0.000 [Unknown error]

Errors which trigger Take when the position is changed. So Take is triggered, deflects a couple of times, then hangs, I change tp to zero to back up and collapse.


Before I change it, I check it

 if ( OrderCloseReason() >= ( int ) ORDER_REASON_SL )

So that the position doesn't freeze.

 
fxsaber :

This is suspicious. Nowhere in my accounts did I find a lack of lag.

I thought the same, but further investigation showed that there were about 100 by Take closures alone

So, to a small sample size.

 

Forum on trading, automated trading systems and testing trading strategies

Acceptance of SL/TP orders

Enrique Dangeroux, 2020.11.25 17:20

Not sure if this is related. But I get a lot of them. 

2020.11.25 16:52:52.992 Trades  '92810': failed modify #1758569 sell 0.02 USDJPY sl: 0.000, tp: 104.293 -> sl: 0.000, tp: 0.000 [Unknown error]

I have my whole log in such messages too. Maybe after the weekend the situation will change.

Forum on trading, automated trading systems and testing trading strategies

Acceptance of SL/TP orders

fxsaber, 2020.11.25 16:30

Broker confirmed the problem and managed to find and fix it (will be available after the weekend). But it's hard to say if it was due to MT5.

 

Let us consider schematically some algorithms of the trading floor. For simplicity we will assume that there is only one LP(liquidity provider).


Limit order.

  1. The price from the LP satisfies the price of the trading floor limit order.
  2. Gateway sends this limit order to the LP with a short expiration time.
  3. If Gateway receives a redirect for a part of the limit volume, Gateway will repeat everything from point 1 for the remaining volume in case the tick from the LP has changed during the time of limit processing.

A good Gateway (with the algorithm above) is independent of the trading platform specifics when executing the Limiter.

The algorithm is almost looped and platform-independent. LP spam protection is contained in point 3.


TP-level of an open position.

  1. A tick came from LP
  2. The price is sent to MT5 as a new tick.
  3. If the position is not blocked and the price of the new tick meets the TP level, MT5 creates a TP order.
  4. The Gateway sees that a TP order is born, locks the position and does p.2 of the limit order algorithm.
  5. If it receives a re-jack, then MT5 sends the TP order to history with a reject status. The position is unlocked.

The algorithm is not looped and is platform dependent. It has protection from spam LP.


This algorithm has two disadvantages apart from Gateway-MT5 communication costs.

  • It has been shown in this thread that the birth of a TP order (see point 3) in MT5 has a lag. Therefore, the probability of a TP order being able to execute is lower than if there were no lag.
  • A TP order in MT5 cannot be created without a new tick. This means that if a redirect is received, the Gateway will not do anything until a new tick has arrived in MT5, satisfying the TP level. And precious time to try to execute the TP-level is lost because of this. This also worsens the FillRate.


Improvement.

Smart Gateway in the TP-level algorithm of an open position has p.6:

6. If a new tick has been received from LP during the redirect, its actual value is re-sent to MT5 as a new tick - move to step 2.

This additional point of the algorithm still contains protection from LP spam, but it tricks MT5 into performing point 3. And no precious time is lost waiting for the new tick.


Reality.

From these two algorithms (even in the case of point 6 of the second algorithm) this follows.

An MT5 limit order has a higher FillRate than its equivalent in the form of a TP-level open position. This is the reason why we may often encounter situations during a rollover on the MT5-Hedge where the limit order is executed, but its TP counterpart is not. In such a case CloseBy is done and the Limit order is re-executed with the corresponding volume.


Conclusion.

To increase the FillRate in MT5 transfer the TP levels of open positions into MT5 limit orders.

12345678
New comment
Reason: