Порядок прихода тиков в терминал
Давно тики подгружал в реал-тайме, там проблем не было.
Скорее всего, Вы грузите COPY_TICKS_ALL, а я использовал COPY_TICKS_TRADE (по дефолту там стоит).
COPY_TICKS_ALL - это агрегация двух не синхронизированных потоков: COPY_TICKS_TRADE и COPY_TICKS_INFO. Агрегация происходит задним числом, поэтому и пропуски.
Всем доброго дня!
Брокер Открытие, срочный рынок, реальный счет.
Наблюдаю случаи прихода тиков в терминал не в том порядке, в котором в них указано время. (Это не имеет отношения к порядку прихода тиков и вызовом функции обработки события OnTick(), смотрите ниже)
Посмотрите как этот индикатор будет работать у Вас
- www.mql5.com
На что смотреть?
Полагаю, глазами то что я описал заметить сложно.
На что смотреть?
Полагаю, глазами то что я описал заметить сложно.
А что не сможете сделать логирование?
Спасибо за помощь. Докладываю результаты экспериментов.
Доработал тестовый эксперт, чтобы параллельно сохранять 3 потока тиков.
Поток №1 - тики Ask&Bid (COPY_TICKS_INFO)
Поток №2 - сделки (COPY_TICKS_TRADE)
Поток №3 - все (COPY_TICKS_ALL)
Как и ранее, в каждом потоке сохраняются по мере прихода в файл-1, а после окончания времени теста запрашиваются тики за весь период тестирования и сохраняются в файл-2.
Пару файлов из каждого потока сверяем между собой.
Запускал несколько раз, суммарно записано более 3-х часов тиков на инструменте Si-9.19.
В потоке всех тиков также как и раньше встречаются пропущенные при периодических обновлениях тики. Во всех случаях тик с изменением цены видимо приходил раньше чем один или несколько тиков со сделками. При следующем обновлении эти тики уже не могли быть получены в связи с тем, что в следующем запросе интервал начинался с времени более позднего тика с ценой.
При этом разница во времени у пропущенных тиков и того, который пришел раньше, в большинстве случаев не больше 3 мс, в одном случае 11. Это позволяет предположить величину задержки между поступлением потоков тиков.
В потоке Ask&Bid нет отличий во времени, цене Ask, цене Bid. Но бывают отличия в полях соответствующих сделкам: цена Last и объем. В большинстве случаев, время, где встречаются эти отличия совпадают с временами пропущенных тиков в общем потоке.
В потоке сделок отличий между сохраненными по мере прихода и сохраненными по окончанию нет. Включая поля цены Ask, цены Bid.
На основании всего сказанного можно сделать следующие выводы:
Поток сделок и поток цен являются отдельными.
Поток тиков COPY_TICKS_ALL является объединением двух потоков (как выше указал fxsaber).
Поток цен идет с опережением потока сделок на 3-11 мс. Однако нельзя утверждать, что это опережение будет стабильным, возможно порядок потоков и задержка между ними может меняться.
Итак, если есть необходимость работать как с тиками Ask&Bid, так и с тиками сделок, то возможны следующий варианты:
1) использовать их как два независимых потока;
2) загружать потоки независимо и агрегировать их самостоятельно, в этом случае возможны нарушения порядка следования тиков по времени в пределах небольших интервалов.
3) загружать общий поток тиков (COPY_TICKS_ALL), но отбрасывать из него тики за последние n мс. И подгружать пропущенный интервал при следующих обновлениях. Это даст некоторую задержку в обновлении данных.
Попутно с экспериментом замерял время, которое тратятся на обновления тикового потока, чтобы понять с какой частотой можно получать обновления тиков при работе с многими инструментами.
Время выполнения функции CopyTicksRange() очень мало, настолько, что практически всегда GetTickCount дает то же самое число.
Однако выяснилась интересная деталь. Если запрашивать данные за текущий день, то CopyTicksRange() выполняется очень быстро, порядка 0 мс.
Если же запросить данные за вчерашний день или более ранний, то время выполнения CopyTicksRange() значительно больше: 15-60 мс. Число получаемых при этом данных такое же или даже меньше.
Как показали эксперименты при запросе c флагом COPY_TICKS_TRADE (как у вас) или COPY_TICKS_INFO пропусков в потоках тиков не происходит.
COPY_TICKS_ALL - это агрегация двух не синхронизированных потоков: COPY_TICKS_TRADE и COPY_TICKS_INFO. Агрегация происходит задним числом, поэтому и пропуски.
Благодарю, все так и оказалось.
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования
Всем доброго дня!
Брокер Открытие, срочный рынок, реальный счет.
Наблюдаю случаи прихода тиков в терминал не в том порядке, в котором в них указано время. (Это не имеет отношения к порядку прихода тиков и вызовом функции обработки события OnTick(), смотрите ниже)
Как провожу эксперимент:
В советнике по таймеру подгружаю новые тики.
Тики запрашиваются функцией CopyTicksRange(). В качестве начального времени в запросе указывается время последнего тика, полученного в прошлом запросе (в первый раз используется текущее время).
Соответственно в получаемом массиве всегда минимум один тик - последний с прошлого времени. Иногда таких тиков несколько, когда у нескольких последних тиков одинаковое время. Такие дублирующие тики из массива удаляются.
Полученные тики сохраняются по мере поступления в лог-файл №1.
Через заданное время советник прекращает запись и выполняет запрос функцией CopyTicksRange() на весь период работы советника. Результат сохраняется в лог-файл №2.
Сравниваю два файла. Иногда они совпадают.
Но иногда наблюдается такая ситуация:
Запрос "за раз" всего периода работы: _______________ Периодические запросы:
Видимо тик с временем 13:09:05.834 пришел раньше тиков со сделками 13:09:05.832. Соответственно, эти тики были пропущены запросами из таймера, так как после получения тика .834 в запросе будет начальное время .834.
Вариант собственной криворукости не исключаю, но вроде бы все проверил.
Аналогичные проверки на AMP Global Clearing (демо) - тики полученные при периодической подгрузке и тики, полученные в конце одним запросом всегда совпадают, даже при наблюдении часами.
В связи с этим несколько вопросов:
1) Кто-нибудь кроме меня такое наблюдал?
2) Является ли это нормальным для терминала?
3) Есть ли идеи как оптимально обнаружить подгрузку тиков раньше последнего?
Готов предоставить тестового эксперта.