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

[fxsaber]

Andrey Khatimlianskii #:

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

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

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

[Andrey Khatimlianskii]

fxsaber #:

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

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

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

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

[fxsaber]

Andrey Khatimlianskii #:

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

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

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

[fxsaber]

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]

fxsaber #:

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

Накопал.

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

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

[fxsaber]

fxsaber #:

Накопал.

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

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

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

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

[prostotrader]

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

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

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

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

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

[fxsaber]

prostotrader #:

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

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

[Sergey Gridnev]

prostotrader #:

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

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

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

[fxsaber]

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. На серверах, где это значение нулевое, ситуация такая же.