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

Новый комментарий
 
Andrey Khatimlianskii #:

Кстати, да, интересно. Если маленький лимитник стоит на том же уровне, где ТП огромной позиции, и этот ТП реджектится, потому что большой, лимитник даже шансов не будет иметь на заливку?

Неправильное предположение. Очередь тейков истекает, когда все тейки отправлены. Т.е. лимитники ждут отправки всех тейков, а не результатов это отправки.

Затормозить отправку чужого лимитника можно не большим объемом тейка, а большим количеством тейков на ценовом уровне лимитника. Например, мин. лотом.

 
fxsaber #:

Неправильное предположение. Очередь тейков истекает, когда все тейки отправлены. Т.е. лимитники ждут отправки всех тейков, а не результатов это отправки.

Затормозить отправку чужого лимитника можно не большим объемом тейка, а большим количеством тейков на ценовом уровне лимитника. Например, мин. лотом.

Ну, хоть так. Все лучше, чем последовательно исполнять все ТП и лимитки.

Но исправить очередь, конечно, нужно. ТП должен быть обычным лимитником.

 
Andrey Khatimlianskii #:

Ну, хоть так. Все лучше, чем последовательно исполнять все ТП и лимитки.

Но исправить очередь, конечно, нужно. ТП должен быть обычным лимитником.

Здесь значительно подробнее по теме. С примерами.

Длительность исполнения торговых приказов
Длительность исполнения торговых приказов
  • www.mql5.com
Величина различия в мат. ожиданиях одной и той же торговой стратегии в Тестере и на реальном счете зависит не только от компетенции автора робота, но и от качества исполнения торговых приказов
 
fxsaber #:

Здесь значительно подробнее по теме. С примерами.

Якобы активирующий TP-ордер тик появился после того, как родился TP-ордер! Т.е. сначала родился TP-ордер, а только потом тик, который вызвал рождение TP-ордера. Звучит бредово. Поэтому подробно разбираемся на картинке.

Скрипт не ошибся, все так! Это значит, что БД тиков заполняется с огромным лагом. И время тика проставляется, как время записи. Т.е. ошибочное время тика.


Так нашелся архитектурный баг MT5.

Воспроизведение данного бага на MQ-Demo с первого раза.

#include <MT4Orders.mqh> // https://www.mql5.com/ru/code/16006

#define Bid SymbolInfoDouble(_Symbol, SYMBOL_BID)
#define Ask SymbolInfoDouble(_Symbol, SYMBOL_ASK)

input int inTP = 10;

// Выставляет противоположные позиции с фиксированным тейком.
void OnStart()
{
  OrderSend(_Symbol, OP_BUY, 0.1, Ask, 0, 0, Ask + inTP * _Point);

  OrderSend(_Symbol, OP_SELL, 0.1, Bid, 0, 0, Bid - inTP * _Point);
}


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

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


Баг воспроизводится не только на MQ-Demo: имеет место даже на реальных счетах. Но на MQ-Demo может быть воспроизведен сразу, как показал выше.


БД тиков на торговом сервере искажена, к сожалению.

Строка для поиска: Oshibka 042.

 
fxsaber #:

Здесь значительно подробнее по теме. С примерами.

Накопал.

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


Очевидно, что и брокерам и, конечно, MQ нужно что-то делать. Рождение тех же тикетов для ордеров должно происходить быстрее даже не на один порядок. Надеюсь, столь скрупулезная запись побудит к изменению ситуации. А пока, действительно, фактор "Авось" имеет место быть в торговле через MT5, часто приводя к несистемным убыткам.

Длительность исполнения торговых приказов - 2
Длительность исполнения торговых приказов - 2
  • www.mql5.com
После существенного улучшения аналитического инструмента провел анализ результатов его применения в разных условиях. После чего возникли гипотезы, для проверки которых создал соответствующие ситуации
 
fxsaber #:

Накопал.

Простыми словами. На скрине MT5 с включенным полным автоматом на исполнение - на сторону никуда ничего не уходит.


TP-ордера сформировались через 104 миллисекунды после прихода активирующего их тика. И далее через 138 миллисекунд исполнились.

Нормальные показатели должны быть на два порядка ниже. Камень в огород.


ЗЫ Лимитные ордера не могли исполняться 104 миллисекунды, т.к. ждали TP-ордера.

Сравнение MQL5 и QLUA - почему торговые операции в MQL5 до 28 раз быстрее?
Сравнение MQL5 и QLUA - почему торговые операции в MQL5 до 28 раз быстрее?
  • www.mql5.com
Многие трейдеры зачастую не задумываются над тем, как быстро доходит их заявка до биржи, как долго она там исполняется, и когда наконец-то торговый терминал трейдера узнает о результате торговой операции. Мы обещали дать сравнение скорости торговых операций, ведь никто до нас не делал таких замеров с помощью программ на MQL5 и QLUA.
 

>> Очевидно, что и брокерам и, конечно, MQ нужно что-то делать. Рождение тех же тикетов для ордеров должно происходить быстрее даже не на один порядок. Надеюсь, столь скрупулезная запись побудит к изменению ситуации. А пока, действительно, фактор "Авось" имеет место быть в торговле через MT5, часто приводя к несистемным убыткам.

К сожалению, уже 6 лет ни Брокеры ни MQ ничего не делают.

На сегодняшний день, задержки на Срочном рынке доходят до секунд, а на Фондовом до минут во время пиковой нагрузки.

Терминал не улучшается в торговой части (прямое его предназначение), а развивается  в сторону "Новогодней елки",

игрушек много, а толку 0. Думается, что ничего меняться не будет, не приносит прибыль....

 
prostotrader #:

ни Брокеры ни MQ ничего не делают.

В данном случае показан метод, который сразу показывает результат. Если что-то подкрутят, то сразу можно будет увидеть эффект. Т.е. не нужно искать лаги, метод их сразу показывает. Гадать с конфигурациями не нужно. Воспроизводится на MQ-Demo с первого раза.

 
prostotrader #:

Терминал не улучшается в торговой части (прямое его предназначение), а развивается  в сторону "Новогодней елки",

игрушек много, а толку 0. Думается, что ничего меняться не будет, не приносит прибыль....

Сложно не согласиться.
 

fxsaber #:

В данном случае показан метод, который сразу показывает результат. Если что-то подкрутят, то сразу можно будет увидеть эффект. Т.е. не нужно искать лаги, метод их сразу показывает. Гадать с конфигурациями не нужно. Воспроизводится на MQ-Demo с первого раза.

57880502
aqtopuw2
MetaQuotes-Demo

Заходим на этот счет и видим все проблемы с лагами формирования и исполнения ордеров.

На этом скрине показаны TP-ордера, которые должны были сработать одновременно, но первые сформировались в 486 мс, а последние - 516 мс (см. красную рамку). Итого 157 ордеров формировались 30 мс. Просто тикеты, без исполнения!


Теперь смотрим длительность исполнения TP-ордеров.


Первые ордера исполнились за 33 мс, последние - 84 мс. На одном и том же ценовом уровне! Демо-контур.


Теперь смотрим, сколько времени прошло с момента прихода тика, что акцептировал TP-ордера, до момента рождения первого TP-ордера и последнего.

Активирующий тик приходит в 462 ms, через 24 мс в 486 создается первый TP-ордер, а через 54 мс после тика создается последний TP-ордер.


Видим, что тормозит торговый сервер непростительно сильно. Повторюсь, это демо-контур: MQ-Demo.


Результат CustomReport в приложении. Каждый может убедиться в наличии лагов на ровном месте, посмотрев HTML-отчет, либо зайдя на сам счет в Терминале.


Просьба форумчан подтвердить наличие тормозов.


ЗЫ AccountInfoInteger(ACCOUNT_LIMIT_ORDERS) = 200. На серверах, где это значение нулевое, ситуация такая же.

Проверь своего брокера!
Проверь своего брокера!
  • 2021.11.12
  • www.mql5.com
На просторах интернета можно видеть довольно частые сценарии торговли. Управляющий ПАММ-счетом набрал инвесторов. Хорошо торговал, но с какого-то момента прибыльность сильно уменьшилась, вплоть до
Файлы:
CustomReport.zip  130 kb
123456789
Новый комментарий