Библиотеки: TradesID - страница 3

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

  • Если история дописалась - нет проблем.
  • Если история задним числом изменилась: удалили ордер/сделку. То TradesID вернет неизвестный результат. Т.к. мы не знаем, в какое место исторической таблицы MT5 попадают (пусть и с прошлым временем) правки задним числом. Я бы не закладывался на такое развитие событий, потому что оно, мягко говоря, странное. Все же торговая история - это Документ. В частности, банки его принимают в качестве объяснения происхождения крупных сумм при снятии денег банковским переводом. Ежесуточно стейт высылается брокером на почту и т.д. Правки задним числом - это больше техническая возможность, нежели реальная.

Что касается реальных сделок - то да. Но есть еще разные технические сделки -  коректировки баланса с нулевым тикетом ордера. Например, на FORTS их много, может быть, и на FOREX у где-то будет. Их в стейменте брокера нет, это чисто MTшный артефакт/особенность. И их могут запросто удалить, как добавили. Не знаю насколько часто такое бывает.

А вот "технических" ордеров не встречал, так что надеюсь, что удаления ордеров не будет.

По поводу отслеживания изменения через транзакции - спасибо за идею!


Еще вопросик. Сколько памяти отжирает заполнения кэша истории при HistorySelect(0, INT_MAX) на счете со 100К+ сделок? Если несложно, посмотрите мой вопрос здесь: https://www.mql5.com/ru/forum/2900/page4#comment_22328244

 
fxsaber:

Выше написал по этому поводу. Вижу техническую возможность.

Понятия не имею, сталкивался ли кто-то с такими значениями (верхние четыре). Ну и выделенное звучит совсем странно. Возможно, в Документации ошибка.

Гипотетически - если есть две встречные позы, то их могут схлопнуть, тогда объемы изменятся.

Или, если маржи у на счете не хватает, возьмут и обрежут позу?

От них, ****** (ДЦ), всего ожидать можно :-)

 
mktr8591:

Гипотетически - если есть две встречные позы, то их могут схлопнуть, тогда объемы изменятся.

Будет две OutBy-сделки в этом случае.

Или, если маржи у на счете не хватает, возьмут и обрежут позу?

Будет срабатывание MarginCall - это ордер, инициированный торговым сервером. Соответственно, последует и сделка.

 
mktr8591:

Но есть еще разные технические сделки -  коректировки баланса с нулевым тикетом ордера.

Такая корректировка - это всегда увеличение HistoryDealsTotal. Если корректировка ошибочная, то даже в этом случае никто не правит прежнюю корректировку, а добавляют новую.

Раньше был мошеннический способ слива - делали ошибочный депозит на миллион, а когда открывал (советник) огромные лоты, снимали этот миллион с комментарием, что ошиблись с начислением. Соответственно, счет обнулялся из-за маржинальных перекосов. При этом если большие лоты давали плюс, то эти сделки отменялись, ведь миллион же липовый, клиент должен понимать. В общем, сплошные плюсы для ДЦ.


Вот как там происходило корректировка - надо смотреть на форумах. Лучшее решение - торговать в правильных местах.

Еще вопросик. Сколько памяти отжирает заполнения кэша истории при HistorySelect(0, INT_MAX) на счете со 100К+ сделок? Если несложно, посмотрите мой вопрос здесь: https://www.mql5.com/ru/forum/2900/page4#comment_22328244

Таблица из >100К записей на некоторых счетах есть. Никаких проблем с прожорливостью Терминала с большим количеством советником не замечал. В числах не замерял вопрос.

 
fxsaber:

Таблица из >100К записей на некоторых счетах есть. Никаких проблем с прожорливостью Терминала с большим количеством советником не замечал. В числах не замерял вопрос.

Заметил.

HistoryDealsTotal() = 42025
HistoryOrdersTotal() = 61743

Такие невысокие показатели выделяют для каждого советника 100Мб на исторический кеш.


Запустить 10 советников с одной лишь строкой

HistorySelect(0, INT_MAX);

и 1Гб выжран будет тут же Терминалом. Поэтому желательно в советники вшивать как можно больше сетов (ТС). И, видимо, переоткрывать счета, чтобы история обнулялась.

 
Решение задачи потребовало пересмотреть механизм синхронизации, выявив массу незнакомых нюансов.... обновлен ByPass.mqh.
 

Обновлен ByPass.mqh. Отрабатывает правильно ситуацию удаления частично исполненного ордера. Добавлено логирование при возникновении проблем.

Пока не исправили, рекомендую работать на b2958.

 

Скрупулезный анализ большого количества логов выявил наличие багов MT5: от формирования исторического кеша Терминала до проблем на стороне Сервера.

Библиотека обновлена - все mqh-файлы. Скорее всего, потенциальные проблемы решены не все. Как всегда, жду помощи в виде логов.


В ToString добавлен еще один показатель.

MT4ORDERS::ByPass: Amount = 0/65035 = 0.00%, Time(mcs) = 0/1353195 = 0.00%, TimeAvg = 20 mcs, MaxInterval = 4183 mcs., Bugs = 0

Он показывает, сколько багов было зафиксировано. Подробные данные пишутся в лог. Так что если глушите Print/Alert, данных не будет.

 
fxsaber:

2 вопроса по BYPASS:

1.  line 156 IsPosOrder():

Res = ((::HistoryOrderGetInteger(Order, ORDER_STATE) != ORDER_STATE_FILLED) ||
                   (ResTmp = (::HistoryOrderGetInteger(Order, ORDER_TIME_DONE_MSC) < TicketTime)) ||
                   ((Order != PositionID) ? (!::PositionSelectByTicket(PositionID) ||
                                             (::PositionGetInteger(POSITION_TIME_UPDATE_MSC) >= ::HistoryOrderGetInteger(Order, ORDER_TIME_DONE_MSC)))
                    : ::PositionSelectByTicket(PositionID)));

Как я понимаю,  проверка делается только если статус равен ORDER_STATE_FILLED, иначе Res=true, те "пропускаем ордер".  Но если сработал рыночный или лимитный ордер IOC, частично выполнился и остаток был отменен, то он будет _CANCELED. При этом его выполненная часть может еще не отразиться в текущей позиции, т.е. имеется рассинхронизация.

IsPosOrder в этом случае отработает некорректно? если да, то нужно добавить проверку на статус  _CANCELED с проверкой объемов INITIAL и CURRENT?


2. Как я понял, ByPASS обрабатывает все возможные виды рассинхронизации, кроме одного: если ордер выполнился, еще находится в списке живых, но PositionsTotal() уже обновился с учетом выполнения этого ордера - см пример в вашем посте, пункт 12?:

https://www.mql5.com/ru/forum/368178/page11#comment_22140275

Или это тоже как-то обрабатывается?

Великий и ужасный МТ4 навсегда (или как грамотно выработать стратегию перехода)
Великий и ужасный МТ4 навсегда (или как грамотно выработать стратегию перехода)
  • 2021.04.30
  • www.mql5.com
Хочу затронуть самую что ни на есть щекотливую тему терминалов МТ4 и МТ5. Их влияние и популярность среди пользователей и брокеров / ДЦ...
 
mktr8591:

2 вопроса по BYPASS:

1.  line 156 IsPosOrder():

Как я понимаю,  проверка делается только если статус не равно ORDER_STATE_FILLED, иначе Res=true, те "пропускаем ордер".  Но если сработал рыночный или лимитный ордер IOC, частично выполнился и остаток был отменен, то он будет _CANCELED. При этом его выполненная часть может еще не отразиться в текущей позиции, т.е. имеется рассинхронизация.

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


Более того, Вы можете видеть в условии, что если ордер открывает позицию, то даже при невозможности выбрать позицию будет возвращено true.


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

IsPosOrder в этом случае отработает некорректно? если да, то нужно добавить проверку на статус  _CANCELED с проверкой объемов INITIAL и CURRENT?

Это первое, что пришло на ум, когда писал. Но ситуации, что описал выше, не позволили такое использовать. ByPass не действует идеально, но там, где возможно, сообщает о рассинхроне. Не забывайте, что очень важно еще не сделать вычислительно тяжелые проверки. Все же не занудства ради проверки, а для очень активного использования (в моем случае).

12345
Новый комментарий
Причина обращения: