Acceptance of SL/TP orders - page 4

New comment
 
Enrique Dangeroux:

https://www.mql5.com/ru/forum/341117 is still a current problem

The last time I checked, this problem was solved on the mentioned broker.

 

Dear developers, please answer the following question on architecture. The information is needed for a combat application. No claims.


There are two limiters with the same price and different lots. What does their ordering in the activation trigger sequence depend on?

I have several answers to this question.

  1. On the lot.
  2. On the ticket number.
  3. From the last modification of the opening price.
  4. From the last modification of an order (for example, the take level was updated at a Limit order).

If I understand correctly, then after modifying the opening price the limiter is appropriately built into the list-table of all Limiters of the server, sorted by opening price. Then the answer to the question comes down to, is it embedded at the beginning of the list of orders with the same price or at the end?


The same question is not about limiters but about tokens. What does the order of triggering identical tokens depend on? Is it an ID position or something else?


Let me explain how this might help in combat. For example, I have two limiters (or position tees) at the same level, but with different lots. If the execution of the limit (tee) depends on the last modification, then I can raise the FillRate simply by modifying the limiters by increasing the lot.


Probably, only someone who wrote the implementation of the corresponding MT5 server part knows the answer to this question.

 
Andrei Trukhanovich:

work together with a broker to find the bottleneck

What is it, bees versus honey?)
 
fxsaber:

There are two limiters with the same price and different lots. What does their order in the activation trigger sequence depend on?

I have several answers to this question.

  1. On the lot.
  2. On the ticket number.
  3. From the last modification of the opening price.
  4. From the last modification of an order (for example, the take level was updated at the limit).

I think variant 4 was used in the fourth one. That is, any modification moved the order to the end of the queue of the corresponding price level.

 
secret:
It's like, bees versus honey?)

at this particular moment in this particular situation, it is mutually beneficial and has been done. a rare coincidence.

 

TP orders in MT5 are remarkable in that we can investigate the FillRate (which part of the order is filled).

The analysis of tens of thousands of such orders has shown that the FillRate depends very much on the symbol. If a pack of TP orders is triggered simultaneously, then the FillRate decreases as the number of the order in the pack increases.

Other specific nuances were also revealed. But this is already discussed with the broker.


The recipe for increasing the FillRate: combining all the same ticks and limiters into one common MT5 limit.


However, this data is only a bonus to this topic. The broker-independent problem is that MT5 is lagging with ticks and consequently with the acceptance of pending orders (including SL/TP levels).


And after a redirect, MT5 waits every time for the next tick to check if the price satisfies the TP level (or limit) or not. This can take up to seconds. And the check should always be done immediately after the regect (or partial fill).

Files:
CheckOrders2.mq5  10 kb
 
fxsaber:

OnTick is triggered a few milliseconds later than the tick is written to the trade server.

// Измеряет размер лага между приходом тика на MT5-сервер и MT5-Терминал.
// Запускать на той же машине, на которой установлен MT5-сервер.

#include <WinAPI\WinAPI.mqh>

input int inPeriod = 10;  // EMA-period
input int inAmount = 100; // Количество тиков для анализа

// Локальное время в миллисекундах.
long TimeLocalMsc()
{
  SYSTEMTIME SystemTime;
  
  kernel32::GetLocalTime(SystemTime);

  MqlDateTime time;
  
  time.year = SystemTime.wYear;
  time.mon = SystemTime.wMonth;
  time.day = SystemTime.wDay;
  time.hour = SystemTime.wHour;
  time.min = SystemTime.wMinute;
  time.sec = SystemTime.wSecond;


  return((StructToTime(time) * 1000 + SystemTime.wMilliseconds));
}

double EMA = 0;
int MaxValue = 0;
int MinValue = INT_MAX;
int Amount = 0;

void OnTick()
{
  static const double Alpha = 1.0 / inPeriod; // EMA-коэффициент для расчета среднего значения.

  MqlTick Tick;
  
  const long time = TimeLocalMsc(); // Локальное время в миллисекундах

  if (SymbolInfoTick(_Symbol, Tick))
  {
    const int Value = (int)(time - Tick.time_msc); // На сколько локальное время отличается от тика.
    
    MaxValue = MathMax(Value, MaxValue); // Максимальное значение.
    MinValue = MathMin(Value, MinValue); // Минимальное значение.
    
    EMA += (Value - EMA) * Alpha; // Среднее значение
    
    if (++Amount >= inAmount) // Если посчитали все тики - распечатываем и выходим.
    {
    #define  TOSTRING(A) #A + " = " + (string)(A) + "\n"      
      Print(TOSTRING(Amount), TOSTRING(MinValue) + TOSTRING(MaxValue) + TOSTRING(EMA) +
            TOSTRING(TerminalInfoInteger(TERMINAL_PING_LAST)));
      
      ExpertRemove();
    }
  }
}


Result.

Amount = 100
MinValue = 1
MaxValue = 8
EMA = 4.344007436833947
TerminalInfoInteger(TERMINAL_PING_LAST) = 42


100 ticks were processed. The arrival lag between the server and the tick terminal varies from one to eight milliseconds. The average is a little over four milliseconds. This is just equal to the lag of TP order triggering, which is where this branch started.


The lag itself is inside the MT5 server. The Server->Terminal channel has nothing to do with it.


Big request to developers to eliminate this lag. Now with zero pings we have a constant delay of ticks incoming not only to the terminal, but to the Server as well. In particular, order accepts.


ZS For those who strip kitchen brokers through arbitrage, this built-in lag is like mana from heaven. I.e. brokers incur substantial additional risk.

 
On what server did you check?

On what tool and what gateway/dataphide did you use to form the initial data?

If the time was generated by a quote provider on its remote side (e.g. exchange gateway) and not the MT5 server itself, then there may be a gap.

What background processes could you forget about, such as stress tests with tens and hundreds of thousands of parallel trades?
 

Renat Fatkhullin:
На каком сервере проверяли?

Checked on many servers. Including MQ-Demo.

Forum on trading, automated trading systems and trading strategy testing

Acceptance of SL/TP orders

fxsaber, 2020.11.25 00:47

Result of running it on MQ-Demo.

Total Orders (from 2020.09.01 00:00:00) = 58493, calculated = 439
Calculation time = 00:00:11.328, Performance = 38.0 orders/sec.

ServerName: MetaQuotes-Demo

Last Tick 2020.09.30 19:07:32.917 1.80181 1.80205
Accepted Tick 2020.09.30 19:07:32.716 1.80178 1.80202
Accepted Length = 357 ms.
Order 726444166 ORDER_TYPE_BUY GBPAUD 2020.09.30 19:07:33.073 1.80206 ORDER_REASON_TP ORDER_STATE_FILLED 2020.09.30 19:07:33.082, Position created 2020.09.30 17:21:17.933, StopLevel = 0

Orders (2) before 726444166 with PositionID = 725926764:
------------------------
Checked Orders = 0
------------------------


The script claims to have found a TP order and a tick which was the trigger for its creation (highlighted in colour in the text). It would seem that if the price has reached the TP level of an open position on the trade server (especially on the demo), the corresponding TP order should be created (not necessarily executed) immediately. However, in this situation it happened not immediately, but after 357 milliseconds!


On which instrument and which gateway/dataphide formed the initial data?

I checked forex tools, RannForex-Server, AMTS-gateway. Other configurations need to be clarified.

If the time was formed by the quotes provider on its remote side (for example, the exchange gateway), and not the MT5 server itself, then the gap can be.

I believe that MT5 server was forming on a machine with zero ping. But requires clarification for a 100% guarantee. However, the above showed that even on your server the problem.

 
fxsaber:

When investigating TP order execution, I noticed that some TP orders were created with a significant lag from the ticks that accepted them.

The debriefing showed that this situation is repeated not only on different brokers, but also in the situation when trading is done on the Terminal, which is on the same machine as the Trading Server. I.e. with a very low ping and a single trading account for the Trading Server.

I encourage you to share the results from your accounts. Help improve the MT5!

You "forgot" a very small detail - you checked 58,000 orders and found only one case of overshoot at 300 ms. And you should have clearly focused on this (1 out of 58 000) during these checks.

Just like in the previous ones with million-dollar checks where you also looked for a single outlier and pretended that it was normal behavior.


We checked the server's logs and we could see that our virtualization with MetaQuotes-Demo server was physically sick in those seconds (at 2020.09.30 19:07 for 4 seconds), because there were about 15 mln accounts and about 2 mln open positions, and in the meantime something was happening on the neighboring virtual servers and hypervisor.

In any case, we'll look into it further, although there are always single spikes in any system.

12345678
New comment