Где взять время с миллисекундами? - страница 2
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Чтобы получить более подходящий совет скажите для чего вам надо знать время с такой точностью.
Любители WinApi забывают о том, что .dll вызывается исключительно по какому либо событию. Чаще всего это приход нового тика. А если в это время нужно именно в этот момент, то не́зачем городить огород и проще взять из структуры MqlTick
Для информации - в МТ5 мы разгоняем системный таймер и GetTickCount с точностью до 1 мс.
Как вариант, предлагаю добавить в структуру MqlDateTime
Windows многозадачная, в ней работают (последовательно переключаются) десятки процессов. Поэтому даже если счетчик компьютера изменится, ваш процесс узнает об этом только на N миллисекунд позже, причем N непостоянно и точность его не гарантирована.
Нет.
Запустите в непрерывном цикле вывод значений времени из dll и GetTickCount и вы увидите, что одно меняется с шагом в 1 мс, а второе меняется прыжками по 15-16.
Это конкретно особенность этой функции.
Кстати частота вызовы OnTimer тоже ограничены этим шагом. Даже при EventSetMillisecondsTimer( 1 ) пауза все равно 15-16 мс, это на картинке выше видно: 492,508,523,539. Простым способом сделать интервал вызова OnTimer меньше 15-16 мс нельзя.
А вот Sleep() можно сделать меньшим, он ограничен только таймером операционной системы, который до периода 0,5 мс разгоняется.
Насчет многозадачности - если компьютер "просто включен" и не занят какой-нибудь задачей на всех ядрах, то N, про который вы пишите, может быть меньше 1 мс.
Для информации - в МТ5 мы разгоняем системный таймер и GetTickCount с точностью до 1 мс.
Это было бы очень здорово.
А то чтобы получить частоту вызовов OnTimer выше 15 мс приходится городить огород с ChartEvents.
А в бесконечном цикле со Sleep нельзя получать торговые транзакции и стаканы.
Кстати не будете ли столь любезны подтвердить или опровергнуть мою догадку, что у событий графика, торговых транзакций и стаканов общая очередь событий? При перегрузке очереди графика с помощью EventChartCustom пропускать транзакции начинает.
И может не останавливаться на 1 мс? Предел системного таймера обычно 0,5 мс.
Насчет многозадачности - если компьютер "просто включен" и не занят какой-нибудь задачей на всех ядрах, то N, про который вы пишите, может быть меньше 1 мс.
Да. Но если загрузить, то в этих 1мс из dll тоже начнутся пропуски.
Чтобы получить более подходящий совет скажите для чего вам надо знать время с такой точностью.
Любители WinApi забывают о том, что .dll вызывается исключительно по какому либо событию. Чаще всего это приход нового тика. А если в это время нужно именно в этот момент, то не́зачем городить огород и проще взять из структуры MqlTick
В MqlTick приходит отметка времени, выставленная по системному таймеру сервера. Насколько он синхронизирован с астрономическим временем, большой вопрос. Ответ на него я искал в 2016. Заскриншотил окна обзора рынка одновременно работающих 31 терминала на одном экране компьютера. Вручную переписал время, которое дают ДЦ в один момент, и вручную занес в таблицу для 25 валютных пар. Посчитал отклонение от среднего для 25 пар. Вот эти данные, по вертикали - секунды.
Причина, по которой ДЦ не хотят синхронизировать свое время с астрономическим, может относиться к правилам разбора претензий (по лог-файлам сервера), к халатности сотрудников и пр. Но реальность такова. Публичное котирование очень непопулярно среди ДЦ. Какие уж тут миллисекунды брать в структуре MqlTick... Поэтому приходится самостоятельно синхронизировать время системного таймера (у меня выходит до 12 мс) с астрономическим и проставлять штамп времени по моменту, когда информация становится доступной для анализа.
В MqlTick приходит отметка времени, выставленная по системному таймеру сервера. Насколько он синхронизирован с астрономическим временем, большой вопрос. Ответ на него я искал в 2016. Заскриншотил окна обзора рынка одновременно работающих 31 терминала на одном экране компьютера. Вручную переписал время, которое дают ДЦ в один момент, и вручную занес в таблицу для 25 валютных пар. Посчитал отклонение от среднего для 25 пар. Вот эти данные, по вертикали - секунды.
Видно, что сдвиги таймеров ДЦ носят систематический характер, то есть налицо общий сдвиг таймера для всех 25 валютных пар в одном ДЦ.
Причина, по которой ДЦ не хотят синхронизировать свое время с астрономическим, может относиться к правилам разбора претензий (по лог-файлам сервера), к халатности сотрудников и пр. Но реальность такова. Публичное котирование очень непопулярно среди ДЦ. Какие уж тут миллисекунды брать в структуре MqlTick... Поэтому приходится самостоятельно синхронизировать время системного таймера (у меня выходит до 12 мс) с астрономическим и проставлять штамп времени по моменту, когда информация становится доступной для анализа.
В как вы учитываете время от отправки тика с сервера до его получения в вашем терминале? Что-то мне кажется, всё это… простите мартышкин труд.
В как вы учитываете время от отправки тика с сервера до его получения в вашем терминале? Что-то мне кажется, всё это… простите мартышкин труд.
тут еще вопрос - откуда известно точное астрономическое время выхода информации %)
Для информации - в МТ5 мы разгоняем системный таймер и GetTickCount с точностью до 1 мс.
Не понимаю Вас. Почему сейчас? Годами здесь просят сделать такую функцию для TimeLocal и TimeCurrent.
ЗЫ В Тестере по какой-то причине нет миллисекунд. Они не пишутся в tst-файл.