ФорумРазделы

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

Новый комментарий
Эту бы информацию разослать всем мега-HFT-шникам МТ-шным, шучу шучу)) Издержки дешевизны это.
fxsaber:

В другой ветке было неоднократно заявлено, что даже Терминал тормозит от огромного количества факторов. Как следствие, гораздо более сложный Торговый сервер обязан тормозить еще больше. Надеюсь все же, что алгоритмическая оптимизация еще возможна. Даже 5 мс лаг - уже очень плохо. Что уж говорить о сотнях миллисекунд.

Что на демо - не очень интересно (там можно отлаживать любые плагины, тестировать новое железо, ...).

А на живых счетах нашел максимум 17 мс (не говорю, что это мало, просто не идет ни в какое сравнение с 30 секундами).

Поэтому и подозрение на кастумную настройку сервера.

Andrey Khatimlianskii:

Что на демо - не очень интересно (там можно отлаживать любые плагины, тестировать новое железо, ...).

А на живых счетах нашел максимум 17 мс (не говорю, что это мало, просто не идет ни в какое сравнение с 30 секундами).

К сожалению, не показали, сколько ордеров проверили.

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

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

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.

Поэтому и подозрение на кастумную настройку сервера.

Брокер подтвердил проблему и сумел ее найти и исправить (после выходных будет доступно). Но сложно сказать, было ли это из-за MT5.


А вот кидать в сторону MT5 камни можно точно по этой ситуации.

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

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

fxsaber, 2020.11.25 00:47

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



Терминал и Сервер на одной машине. Загрузка нулевая. Свежий тейк получил такой алерт.

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


Лог сервера.

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]


Акцепт-тик на сервере.


Полное подтверждение данных скрипта, что проблема есть. Внутри сервера при нулевой загрузке произошел лаг на 4 мс.

Andrei Trukhanovich:

очередной взрыв мозга от fxsaber.

Особенно сильно ощущается, когда понимаешь, сколько времени убил. И что за тебя никто этого не сделает.

Кажется, действительно проблема на сервере. Это демо-счет MT5

 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

На реальном счете у того же брокера скрипт возвращает нулевые результаты. На счету более 3000 транзакций.

Enrique Dangeroux:

На реальном счете у того же брокера скрипт возвращает нулевые результаты. На счету более 3000 транзакций.

Это подозрительно. Нигде на своих счетах отсутствие лагов не обнаружил.

Не уверен, связано ли это. Но я получаю их много 

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]

Ошибки, при изменении позиции которых срабатывает Take. Таким образом, Take срабатывает, пару раз отклоняет, затем зависает, я изменяю tp на ноль, чтобы подстраховаться и обрушиться.


Перед изменением я проверяю это

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

чтобы положение не застыло.

fxsaber :

Это подозрительно. Нигде на своих счетах отсутствие лагов не обнаружил.

Я думал то же самое, но дальнейшее расследование показало, что только там было закрыто около 100 by Take

Итак, к небольшому объему выборки.

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

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

Enrique Dangeroux, 2020.11.25 17:20

Не уверен, связано ли это. Но я получаю их много 

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]

У меня тоже весь журнал в таких сообщениях. Возможно, после выходных ситуация изменится.

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

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

fxsaber, 2020.11.25 16:30

Брокер подтвердил проблему и сумел ее найти и исправить (после выходных будет доступно). Но сложно сказать, было ли это из-за MT5.

Рассмотрим схематично некоторые алгоритмы торговой площадки. Для упрощения будем считать, что имеется только один LP (поставщик ликвидности).


Лимитный ордер.

  1. Цена от LP удовлетворяет цене лимитника торговой площадки.
  2. Gateway шлет этот лимитник на LP с коротким временем экспирации.
  3. Если получает реджект на часть объема лимитника, то Gateway повторяет все из п.1 для оставшегося объема в случае, если тик от LP изменился за время обработки лимитника.

При исполнении лимитника хороший Gateway (с алгоритмом выше) не зависит от особенностей торговой платформы.

Алгоритм почти зацикленный и платформо-независимый.  Защита от спама LP содержится в п.3.


TP-уровень открытой позиции.

  1. Пришел тик от LP
  2. Цена отправляется в MT5 в виде нового тика.
  3. Если позиция не заблокирована и цена нового тика удовлетворяет TP-уровню, то сам MT5 создает соответствующий TP-ордер.
  4. Gateway видит, что родился TP-ордер, блокирует позицию и делает п.2 из алгоритма лимитных ордеров.
  5. Если получает реджект, то в MT5 отправляет TP-ордер в историю со статусом reject. Позицию разблокирует.

Алгоритм не зацикленный и платформо-зависимый. Имеется защита от спама LP.


У этого алгоритма два минуса, если не считаться с издержками связи Gateway-MT5.

  • В данной ветке было показано, что рождение TP-ордера (см. п.3) в MT5 происходит с лагом. Поэтому вероятность успеть исполниться ниже, чем если бы лага не было.
  • TP-ордер в MT5 не может родиться без нового тика. Это значит, что если получили реджект, то Gateway ничего не будет делать, пока в MT5 не придет новый тик, удовлетворяющий TP-уровню. И драгоценное время на попытки исполнения TP-уровня из-за этого пропадает. Это также ухудшает FillRate.


Улучшение.

Умный Gateway в алгоритме TP-уровня открытой позиции имеет п.6:

6. Если за время реджекта был получен новый тик от LP, то его актуальное значение повторно отправляется в MT5  в виде нового тика - переход на п.2.

Этот дополнительный пункт алгоритма все еще содержит защиту от спама LP, но при этом обманным способом заставляет MT5 выполнить п.3. И драгоценное время на ожидание нового тика не теряется.


Реальность.

Из этих двух алгоритмов (даже в случае наличия п.6 во втором) следует такой расклад.

MT5-лимитный ордер имеет более высокий FillRate, чем его тезка в виде TP-уровня открытой позиции. По этой причине при переворотах на MT5-Hedge можно часто сталкиваться с ситуациями, когда лимитник исполнился, а его TP-тезка - нет. В таком случае делается CloseBy и перевыставляется лимитник с соответствующим объемом.


Вывод.

Для повышения FillRate в MT5 перевод TP-уровней открытых позиций в MT5-лимитные ордера.

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