MT5 and speed in action - page 34

[fxsaber]

fxsaber:

it's not possible to change the story at the weekend, so there's no way to check.

Possibly. That's why the problem was found at the weekend.

// Демонстрация лагов HistorySelect при удалении нескольких ордеров.
#property script_show_inputs

input int inAmount = 5; // Количество ордеров

#include <fxsaber\Benchmark.mqh> // https://c.mql5.com/3/332/Benchmark.mqh
#define _B2(A) _B(A, 10)

// true - ордер есть в истории, false - иначе.
bool HistorySelectOrder( const ulong Ticket )
{
  return((HistoryOrderGetInteger(Ticket, ORDER_TICKET) == Ticket) ||
         (_B2(HistorySelect(0, INT_MAX)) && (HistoryOrderGetInteger(Ticket, ORDER_TICKET) == Ticket)));
}

void OnStart()
{
  HistorySelect(0, INT_MAX); // Создали исторический кеш.
        
  MqlTradeRequest Request = {0};
  MqlTradeResult Result;
                        
  // Выставляем ордера
  Request.action = TRADE_ACTION_PENDING;
  Request.symbol = _Symbol;
  Request.volume = 0.01;
  Request.price = SymbolInfoDouble(_Symbol, SYMBOL_ASK) - 1000 * _Point;
  Request.type = ORDER_TYPE_BUY_LIMIT;
        
  for (int i = 0; i < inAmount; i++)
    if (!OrderSend(Request, Result) || (Result.retcode != TRADE_RETCODE_DONE))
      Print("Good!");
            
  // Удаляем ордера
  Request.action = TRADE_ACTION_REMOVE;

  for (int i = OrdersTotal() - 1; i >= 0; i--)
  {
    Request.order = OrderGetTicket(i);

    if (OrderSend(Request, Result) && (Result.retcode == TRADE_RETCODE_DONE) &&
        !HistorySelectOrder(Request.order)) // Проверяем наличие удаленного ордера в истории.
      Print("OrderSend BUG!");
  }
}

Result.

2020.09.27 15:46:11.940 Alert: Time[Test6.mq5 523: HistorySelect(0,INT_MAX)] = 39 mсs.
2020.09.27 15:46:11.988 Alert: Time[Test6.mq5 523: HistorySelect(0,INT_MAX)] = 253 mсs.
2020.09.27 15:46:12.034 Alert: Time[Test6.mq5 523: HistorySelect(0,INT_MAX)] = 190 mсs.
2020.09.27 15:46:12.083 Alert: Time[Test6.mq5 523: HistorySelect(0,INT_MAX)] = 218 mсs.
2020.09.27 15:46:12.130 Alert: Time[Test6.mq5 523: HistorySelect(0,INT_MAX)] = 250 mсs.

Lags (can go up to several milliseconds) after deleting the second order.

[secret]

Renat Fatkhullin:

Switch to microsecond counting. Milliseconds are no longer appropriate.

Why does the MT5 server execute pending orders in 100-200 milliseconds? (at a well-known broker on A)

[Renat Fatkhullin]

fxsaber:

Perhaps. That's why a problem was found at the weekend.

Result.

Lags (can reach up to several milliseconds) after deleting the second order.

Deletion of orders leads to complete disabled cache of selected history.

In normal mode the speed of history sampling was brought to tens of microseconds.

[Renat Fatkhullin]

secret:

Why does the MT5 server execute pending orders in 100-200 milliseconds? (at a well-known broker on A)

Executes or accepts?

Without details on N trades (so you can see the whole picture, not a torn out single order. including pings) you can't discuss.

[fxsaber]

Renat Fatkhullin:

Deleting orders completely disables the cache of the selected story.

The first deletion goes fine, though. The second one has problems. What is this disability related to?

[fxsaber]

fxsaber:

I'll have to look it up on the forum. I remember showing how Generic access to history is superior to the regular mechanism just in the Tester.

This was the casehere.

[secret]

Renat Fatkhullin:

Does it execute or does it accept?

Without details on N trades (so you can see the big picture, not a torn out single order. including pings) we cannot discuss.

Yes, it is.

If the price touches a pending Limit order with one tick and bounces back, and this tick lasts for less than 100-200 ms. Then approximately in 30-50% of cases slippage occurs. I.e., the order does not have enough time to be executed by the price of the tick.

The duration of tick is checked against the broker's tick archive, therefore pings have nothing to do with it.

I also do not believe in high server load since only few traders at those moments move according to the order numbers.

Slippage due to lack of liquidity also has nothing to do with it. It appears only on short ticks. The lot size is small, too.

So far I assume an artificial delay of execution from the broker's side.

It is time consuming to collect statistics on several trades. But it is possible, if it helps to answer the question.

[Renat Fatkhullin]

secret:

Executes.

If price touches a Limit order with one tick and bounces back, and that tick lasts less than 100-200 ms. Then approximately 30-50% of cases the order is executed with a slippage. I.e., the order does not have enough time to be executed by the price of the tick.

The duration of tick is checked against the broker's tick archive, therefore pings have nothing to do with it.

I also do not believe in high server load since only few traders at those moments move according to the order numbers.

Slippage due to lack of liquidity also has nothing to do with it. It appears only on short ticks. The lot size is small, too.

So far I assume an artificial delay of execution from the broker's side.

It is time consuming to collect statistics on several trades. But it is possible, if it helps to answer the question.

You have to look into it in detail, but if forex, it's likely to be a trade on the next tick.

I need logs and a tick chart table.

[fxsaber]

secret:

If price touches a Limit order with one tick and bounces back, and that tick lasts less than 100-200 ms. Then slippage occurs in about 30-50% of cases. I.e. the order does not manage to be executed at the price of the tick.

MT5 has nothing to do with it. On demo accounts there will be perfect execution.

[fxsaber]

Tired of debugging the snapshots. Finally made it perfect. One advisor, nothing. Two - perfect. 20 - disaster: CPU is under 100%. HistorySelect lags for many milliseconds.

It seems that MT5 is not intended for making many Expert Advisors run simultaneously.