MT5和速度在行动 - 页 34

[fxsaber]

fxsaber:

周末不可能改变故事，所以没有办法检查。

有可能。这就是为什么在周末发现问题的原因。

// Демонстрация лагов 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!");
  }
}

结果。

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.

删除二阶后会出现滞后（可达几毫秒）。

[secret]

Renat Fatkhullin:

切换到微秒计数。毫秒已经不合适了。

为什么MT5服务器在100-200毫秒内执行挂单？(在A市的一个知名经纪人处)

[Renat Fatkhullin]

fxsaber:

也许。这就是为什么在周末发现了一个问题。

结果。

删除二阶后的滞后（可达到几毫秒）。

删除订单会导致所选历史的缓存完全失效。

在正常模式下，历史采样的速度被提高到几十微秒。

[Renat Fatkhullin]

secret:

为什么MT5服务器在100-200毫秒内执行挂单？(在A市的一个知名经纪人处)

执行还是接受？

如果没有N个交易的细节（这样你就能看到全貌，而不是撕掉的单子。包括平局），你就无法讨论。

[fxsaber]

Renat Fatkhullin:

删除订单会使所选故事的缓存完全失效。

不过，第一次删除的时候很顺利。第二个有问题。这种残疾与什么有关？

[fxsaber]

fxsaber:

我必须在论坛上查一下。我记得我展示了通用访问历史是如何优于常规机制的，只是在测试器中。

这里的 情况就是如此。

[secret]

Renat Fatkhullin:

它是执行还是接受？

如果没有N个交易的细节（这样你就能看到大局，而不是撕掉的单子。包括平局），我们无法讨论。

是的，它是。

如果价格触及一个挂起的限价单，并反弹，而且这个点持续的时间小于100-200毫秒。然后大约在30-50%的情况下发生滑移。也就是说，该订单没有时间被tick的价格所执行。

滴答的持续时间是根据经纪人的滴答档案检查的，因此ping与它无关。

我也不相信服务器的高负荷，因为在那些时刻只有少数交易者根据订单号进行移动。

由于缺乏流动性而导致的滑坡也与此无关。它只出现在短线上。地段面积也很小。

到目前为止，我假设经纪人方面的执行是人为的延迟。

收集几个交易的统计数据是很耗时的。但这是可能的，如果这有助于回答问题的话。

[Renat Fatkhullin]

secret:

执行。

如果价格触及限价单的一个刻度并反弹，且该刻度持续时间小于100-200毫秒。然后，大约30-50%的情况下，订单被执行时出现了滑点。也就是说，该订单没有时间被tick的价格所执行。

滴答的持续时间是根据经纪人的滴答档案检查的，因此ping与它无关。

我也不相信服务器的高负荷，因为在那些时刻只有少数交易者根据订单号进行移动。

由于缺乏流动性而导致的滑坡也与此无关。它只出现在短线上。地段面积也很小。

到目前为止，我假设经纪人方面的执行是人为的延迟。

收集几个交易的统计数据是很耗时的。但这是可能的，如果这有助于回答问题的话。

你必须详细调查，但如果是外汇，很可能是下一个交易日的交易。

我需要日志和滴答图表。

[fxsaber]

secret:

如果价格触及限价单的一个刻度并反弹，且该刻度持续时间小于100-200毫秒。然后在大约30-50%的情况下发生滑移。也就是说，该订单没有设法以tick的价格被执行。

MT5与此毫无关系。在模拟账户上，会有完美的执行。

[fxsaber]

厌倦了 对快照的调试。终于使它变得完美。一个顾问，什么都没有。二--完美。20 - 灾难：CPU低于100%。HistorySelect 滞后很多毫秒。

看来，MT5并不打算让许多专家顾问同时运行。