Акцептирование SL/TP-ордеров - страница 4

Новый комментарий
 
Enrique Dangeroux:

https://www.mql5.com/ru/forum/341117 все еще актуальная проблема

Когда последний раз проверял, то на упомянутом брокере эта проблема была решена.

 

Уважаемые разработчики, просьба ответить на следующий вопрос по архитектуре. Информация нужна для боевого применения. Без претензий.


Стоит два лимитника с одинаковой ценой и разными лотами. От чего зависит их очередность в последовательности триггера активации?

У меня несколько вариантов ответа на этот вопрос.

  1. От лота.
  2. От номера тикета.
  3. От последней модификации  цены открытия.
  4. От последней модификации ордера (например, тейк-уровень обновили у лимитника).

Если правильно понимаю, то после модификации цены открытия лимитник соответствующим образом встраивается в список-таблицу всех лимитников сервера, отсортированную по цене открытия. Тогда ответ на вопрос сводится, он встраивается в начало списка ордеров с одинаковой ценой или в конец?


Такой же вопрос не по лимитникам, а по тейкам. От чего зависит очередность триггера одинаковых тейков? ID-позиции или что-то еще?


Поясню, как это может помочь в бою. Например, у меня есть два лимитника (или тейка позиции) на одном уровне, но с разными лотами. Если исполнение лимитника (тейка) зависит от последней модификации, то поднять FillRate можно просто модификациями лимитников по возрастанию лота.


Наверное, на этот вопрос знает ответ только тот, кто писал реализацию соответствующей серверной части MT5.

 
Andrei Trukhanovich:

сообща с брокером найти узкое место

Это как, пчёлы против мёда?)
 
fxsaber:

Стоит два лимитника с одинаковой ценой и разными лотами. От чего зависит их очередность в последовательности триггера активации?

У меня несколько вариантов ответа на этот вопрос.

  1. От лота.
  2. От номера тикета.
  3. От последней модификации  цены открытия.
  4. От последней модификации ордера (например, тейк-уровень обновили у лимитника).

В четверке был вариант 4, кажется. То есть, любая модификация отодвигала ордер в конец очереди соответствующего ценового уровня.

 
secret:
Это как, пчёлы против мёда?)

на данный конкретный момент в этой конкретной ситуации это взаимовыгодно и было сделано. редкое стечение обстоятельств.

 

TP-ордера в MT5 замечательны тем, что можно исследовать FillRate (какая часть ордеров заливается).

Анализ десятков тысяч таких ордеров показал, что FillRate очень сильно зависит от символа. Если одновременно триггерится пачка TP-ордеров, то FillRate падает с увеличением номера тикета в пачке.

Были выявлены и другие специфические нюансы. Но это уже обсуждается с брокером.


Рецепт увеличения FillRate: объединение всех одинаковых тейков и лимитников в один общий MT5-лимитник.


Однако, эти данные являются только бонусом к данной теме. Независимая от брокеров проблема - MT5 лагает с тиками и, соответственно, с акцептом отложенных ордеров (включая SL/TP-уровни).


И после реджекта MT5 каждый раз ждет следующего тика для проверки, удовлетворяет цена TP-уровню (или лимитнику) или нет. Это может затягиваться на секунды. А проверку надо делать всегда сразу после реджекта (или частичной заливки).

Файлы:
CheckOrders2.mq5  10 kb
 
fxsaber:

OnTick срабатывает на несколько миллисекунд позже, чем в торговый сервер записался тик.

// Измеряет размер лага между приходом тика на 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();
    }
  }
}


Результат.

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


Было обработано 100 тиков. Лаг прихода между сервером и Терминалом тиков колеблется от одной до восьми миллисекунд. В среднем - немного больше четырех миллисекунд. Это как раз равно отставанию срабатывания TP-ордеров, с которого началась эта ветка.


Сам лаг находится внутри MT5-сервера. Канал Server->Terminal не при чем.


Большая просьба разработчиков устранить этот лаг. Сейчас на биржах при нулевом пинге имеем постоянное приличное запаздывание прихода тиков не только в Терминал, но и на Сервере. В частности, акцепты ордеров.


ЗЫ Для тех, кто раздевает кухонных брокеров через арбитраж, это встроенное отставание, как мана небесная. Т.е. брокеры несут существенные доп. риски.

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

На каком инструменте и какой шлюз/датафид формировал исходные данные?

Если время формировал поставщик котировок на своей удаленной стороне(например биржевой шлюз), а не сам МТ5 сервер, то разбег может быть.

О каких фоновых процессах вы могли забыть типа стресс-тестах с десятками и сотнями тысяч параллельных торговых операций?
 

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

Проверял на многих серверах. Включая MQ-Demo.

Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий

Акцептирование SL/TP-ордеров

fxsaber, 2020.11.25 00:47

Результат его запуска на 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
------------------------


Скрипт утверждает, что нашел TP-ордер и тик, который был триггером его создания (выделены цветом в тексте). Казалось бы, если на торговом сервере (тем более на демо) цена дошла до TP-уровня открытой позиции, то должен тут же создаться (не обязательно исполниться) соответствующий TP-ордер. Однако, в данной ситуации это произошло далеко не мгновенно, а через 357 миллисекунд!


На каком инструменте и какой шлюз/датафид формировал исходные данные?

Проверял форекс-инструменты. RannForex-Server, AMTS-шлюз. По остальным конфигурациям нужно уточнять.

Если время формировал поставщик котировок на своей удаленной стороне(например биржевой шлюз), а не сам МТ5 сервер, то разбег может быть.

Склоняюсь, что сам MT5-сервер формировал на машине с нулевым пингом. Но требует уточнения для 100%-й гарантии. Однако, выше показал, что даже на Вашем сервере проблема.

 
fxsaber:

Изучая вопросы исполнения TP-ордеров, заметил, что некоторые TP-ордера создавались со значительным отставанием от тиков, которые их акцептировали.

Разбор полетов показал, что эта ситуация повторяется не только на разных брокерах, но и в ситуации, когда торговля идет на Терминале, который стоит на той же машине, где и Торговый Сервер. Т.е. с очень низким пингом и единственным торговым счетом для Торгового сервера.

Призываю делиться результатами со своих счетов. Поспособствуйте улучшению MT5!

Вы "забыли" совсем малую деталь - вы проверяли 58 тысяч ордеров и нашли только один случай выброса на 300 мс. А на этом (1 из 58 000) надо было явно акцентироваться при таких проверках.

Как и в прошлые разы с миллионными проверками, где вы тоже искали одиночные выбросы и делали вид, что это обычное поведение.


Мы проверили логи сервера и видно было, что нашей виртуалке с демо-сервером MetaQuotes-Demo явно физически поплохело в те секунды (в 2020.09.30 19:07 на протяжении 4х секунд), так как на нем в тот момент крутилось около 15 млн счетов и около 2 млн открытых позиций, а параллельно что-то еще творилось на соседних виртуалках и гипервизоре.

В любом случае будем дальше разбираться, хотя одиночные выбросы бывают всегда в любой системе.

123456789
Новый комментарий