2020.05.29 21:56:31.696 Trades '9701161': failed close position #275887435 sell 0.8 EURUSD by position #275890530 [Invalid order]
Прошу рассмотреть предложение.
В структуру
MqlRates добавить два поля price bid, price ask на момент закрытия бара.
Есть необходимость получать эти
значения по приходу нового бара, хотелось бы видеть эти значения в этой структуре, в одном месте.
Тогда исключился бы дополнительный вызов
MqlTick и его проверка, для таких вызовов, которые работают по признаку нового бара.
Цена ласт необходима для идентификации цены
закрытия бара, на момент начала биржевого клиринга, или идентификации скорректированной цены.
Так как цена закрытия во время клиринга
может корректироваться биржей, то цена закрытия последнего бара попадёт в историю только после открытия нового бара, т.е. после
клиринга.
Так как сейчас эта идентификация происходит по поступлению нового бара на открытии, то на момент начала клиринга не возможно
получить цену закрытия последнего бара.
struct MqlRates { datetime time; // время начала периода double bid; // цена Bid в момент завершения периода double ask; // цена Ask в момент завершения периода double last; // цена последней сделки (Last) в момент завершения периода double open; // цена открытия double high; // наивысшая цена за период double low; // наименьшая цена за период double close; // цена закрытия long tick_volume; // тиковый объем int spread; // спред long real_volume; // биржевой объем };
Доброго времени суток. Поскольку проблема достаточно неприятная и перекочевала и в эту версию, буду признателен, если озвучите официальную позицию по этому вопросу: это я что не понимаю и криво делаю, это баг и будет исправлен (когда?), это фича и исправлено не будет (почему?)? Спасибо.
Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий
traveller00, 2020.05.27 15:22
Огромная просьба исправить эту крайне неприятную ошибку.
При торговле лимитниками лимитник не исполняется на текущем тике, а по неизвестным причинам ждёт тика следующего. Цене он полностью удовлетворяет, по стакану тоже, красится жёлтым, но если новых тиков нет на каком-нибудь малоликвидном символе, может висеть так минутами. А дальше как повезёт. Качнётся цена в удачную сторону-исполнится. Качнётся в неудачную-останется висеть. При обычной торговле одним инструментом это неприятно, но в принципе терпимо. При торговле синтетиками это очень сильно обрушает всю стратегию, порой делая её невозможной в принципе.
Эта же ошибка описана в топике https://www.mql5.com/ru/forum/341117 ниже видео с её воспроизведением
2020.05.30 02:26:48.438 : history cache build error
В Терминале были два чарта (50 000 M1-баров, один и тот же символ) и на каждом безындикаторный советник (работает только с символом чарта). Каждый советник сопровождал свои 10 позиций и 10 ордеров.
Никаких тяжелых вычислений в советнике нет. Ценовые данные получает только через SymbolInfoTick и CopyTicksRange (только свежие тики - где-то 0-5 тиков после запроса). Бары не используются. Единственное, что OnTick мог длиться до 5 секунд, т.к. могло случиться до 20 OrderSend в одном OnTick. DLL, ex5-библиотеки, графические ресурсы и объекты не используются.
Терминал зависал на минуту-две. Никаких реакций или визуальных изменений данных. CPU на полную катушку. Потом отвисал.
Заметил, что зависание часто происходило, когда пачки тейков и лимитных ордеров срабатывали разом.
Предполагаю, что очередь событий переполнялась и вызывала ступор Терминала. Если правильно понял Разработчиков, советники не могут вызывать зависание Терминала, т.к. выполняются в других потоках.
В общем, большие вопросы к потреблению CPU/RAM MT5 в простом торговом режиме. Жрет непомерно много. Такой же кроссплатформенный советник на медленном MT4x32 летает (вместо CopyTicks используется HistoryTicks), зависаний не вызывает. Кушает CPU/RAM по минимуму. Что не так?
Относительно сильная машина, но MT5 b24xx на ней иногда работает, как супер-сырая альфа, даже не бета. Уже привык, что даже на выходных при работе с Тестером запросто можно вызвать зависание Терминала. Обычным делом стало убивание terminal64.exe.
Предполагаю, что штатные бета-тестеры MT5 не делают стресс-тестов Терминала.
Только благодаря особенной реализацией своих роботов торговая логика в них не разваливается во время таких выкрутасов Терминала в боевом режиме.
Самое поганое, что невозможно даже хоть как-то продемонстрировать эти проблемы Разработчикам. Поэтому, вероятнее всего, так все и останется бажить. Очень сильно тревожит текущая работа MT5 во время торговли.
ЗЫ Буду делать профайлер, чтобы максимально оптимизировать и так быстрый код.
Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий
Тестер стратегий MetaTrader 5: ошибки, баги, предложения по улучшению работы
fxsaber, 2020.05.30 11:10
2470, при Оптимизации проскакивают такие сообщения.2020.05.30 11:49:55.216 Core 2 genetic pass (15, 313) returned result 0 in 0:00:04.146 2020.05.30 11:49:55.575 Core 1 genetic pass (15, 283) returned result 0 in 0:00:04.907 2020.05.30 11:49:56.241 Core 3 genetic pass (15, 375) returned result 0 in 0:00:04.537 2020.05.30 11:49:56.269 Core 6 genetic pass (15, 495) returned result 0 in 0:00:04.413 2020.05.30 11:49:57.497 Core 4 genetic pass (15, 419) returned result 1908.000000 in 0:00:04.873 2020.05.30 11:49:58.528 Core 6 genetic pass (15, 497) returned result 0 in 0:00:00.135 2020.05.30 11:49:58.528 Core 6 genetic pass (15, 502) returned result 0 in 0:00:02.122 2020.05.30 11:49:58.824 Core 4 genetic pass (15, 428) returned result 0 in 0:00:00.291 2020.05.30 11:49:58.824 Core 4 genetic pass (15, 429) returned result 0 in 0:00:01.035 2020.05.30 11:49:59.178 Core 4 genetic pass (15, 433) returned result 0 in 0:00:00.352 2020.05.30 11:49:59.178 Core 2 2 rejected passes returned to queue 2020.05.30 11:49:59.178 Core 3 2 rejected passes returned to queue 2020.05.30 11:49:59.178 Core 4 genetic pass (15, 345, 1) started 2020.05.30 11:49:59.660 Core 2 genetic pass (15, 327) returned result 0 in 0:00:04.443Что это обозначает? Свободной памяти много.
Прошу рассмотреть предложение.
В структуру
MqlRates добавить два поля price bid, price ask на момент закрытия бара.
Есть необходимость получать эти
значения по приходу нового бара, хотелось бы видеть эти значения в этой структуре, в одном месте.
Тогда исключился бы дополнительный
вызов MqlTick и его проверка, для таких вызовов, которые работают по признаку нового бара.
Цена ласт необходима для
идентификации цены закрытия бара, на момент начала биржевого клиринга, или идентификации скорректированной цены.
Так как цена
закрытия во время клиринга может корректироваться биржей, то цена закрытия последнего бара попадёт в историю только после открытия
нового бара, т.е. после клиринга.
Так как сейчас эта идентификация происходит по поступлению нового бара на открытии, то на момент
начала клиринга не возможно получить цену закрытия последнего бара.
Поддерживаю.
Так же нужно еще одно поле - OI (открытый интерес по фьючерсам). Т.е. при отправке баров М1 на терминал МТ5 серверу необходимо записывать прямо в бары М1 последнее значение ОИ, согласно последним данным биржи (для СМе это будут данные пред. дня, для МОЕХ - он-лайн). Далее при запросе CopyRates выводить эти данные в MqlRates в поле rate.OI , т.о. сделав данные по открытому интересу доступными для полноценного анализа.
Поддерживаю.
Так же нужно еще одно поле - OI (открытый интерес по фьючерсам). Т.е. при отправке баров М1 на терминал МТ5 серверу необходимо записывать прямо в бары М1 последнее значение ОИ, согласно последним данным биржи (для СМе это будут данные пред. дня, для МОЕХ - он-лайн). Далее при запросе CopyRates выводить эти данные в MqlRates в поле rate.OI , т.о. сделав данные по открытому интересу доступными для полноценного анализа.
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования
В пятницу 29 мая 2020 года будет выпущена обновленная версия платформы MetaTrader 5. Обновление содержит следующие изменения:
Обновление будет доступно через систему LiveUpdate.