Особенности языка mql5, тонкости и приёмы работы - страница 92
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Какова вероятность изменения локального времени компьютера между двумя вызовами GetMicrosecondsCount, используемых для замера времени в микросекундах?
Не нулевая.
Очень конструктивная беседа )
Просто еще пяток набрасывателей удалим навсегда и все.
Больше не терпим тех, кто бросается на амбразуру, пытается реальность WinAPI функций назвать багом и обвинить нас. Констуктива будет явно больше.
Не нулевая.
А какова вероятность потери времени на обмен информации клиент/сервер в миллисекундах? Наверно больше чем вероятность изменения локального времени.
Просто еще пяток набрасывателей удалим навсегда и все.
Больше не терпим тех, кто бросается на амбразуру, пытается реальность назвать багом и обвинить нас. Констуктива будет явно больше.
немного правее от темы, в сторону OnTimer() )))
не помню где читал, там представитель MQ писал, что можно ( у кого сильно чешется ) перевести систему на задержку в 1мс и тогда вроде как если используется EventSetMillisecondTimer(...), то OnTimer() так же будет работать с погрешностью примерно в 1 мс, а не 16мс
если я правильно понял, то OnTimer() как раз работает с системной задержкой, правильно?
ps. в сервси-деск отправлял заявку вчера Не обработана, Начата: 2018.07.30 12:52, #2117844, не могли бы вы помочь в ее обработке, а то со вчерашнего дня висит ))OnTimer работает с погрешностью системного WinAPI таймер, контролируемого через WinAPI функцию GetTickCount. Это очень быстрый и дешевый способ замера времени, который оказывает минимальное влияние на замеряемый процесс. То есть, он не сильно портит своим расходом итоговый результат.
Точность этого таймера можно повысить для всей операционной системы, но за это придется заплатить как повышением расхода CPU, так и рандомными и массовыми наведенными эффектами от того, что масса программ начнет:
Проблеме системного таймера Windows уже больше 20 лет. Но поведение и точность старого таймера менять опасно.
Поэтому давно уже введены новые, более точные методы замера времени. Но они ресурсоемкие и их неразумно применять в качестве полной замены старого таймера.
У нас таймер с повышенной точностью реализуется с помощью GetMicrosecondCount. Его нужно применять осознанно и с понимаем, что он обходится дороже чем GetTickCount. Кроме того, стоимость вызовов GetMicrosecondCount должна явно учитываться в случаях точных замеров.
Очень легко неправильным использованием таймера и несоблюдением чистоты бенчмарка обмануть самого себя и других.
Больше не терпим тех, кто бросается на амбразуру, пытается реальность WinAPI функций назвать багом и обвинить нас. Констуктива будет явно больше.
можно же просто написать в справке, что GetMicrosecondsCount зависит от локального времени компа и может неадекватно работать при его модификации. А GetTickCount не зависит.
задача микросекундного замера с учетом проблемы тоже решаема, пусть немного коряво. и ее можно решить на нашем уровне и на вашем. видимо придется решать на нашем.
зачем банить-то?
OnTimer работает с погрешностью системного WinAPI таймер, контролируемого через WinAPI функцию GetTickCount. Это очень быстрый и дешевый способ замера времени, который оказывает минимальное влияние на замеряемый процесс. То есть, он не сильно портит своим расходом итоговый результат.
Точность этого таймера можно повысить для всей операционной системы, но за это придется заплатить как повышением расхода CPU, так и рандомными и массовыми наведенными эффектами от того, что масса программ начнет:
Проблеме системного таймера Windows уже больше 20 лет. Но поведение и точность старого таймера менять опасно.
Поэтому давно уже введены новые, более точные методы замера времени. Но они ресурсоемкие и их неразумно применять в качестве полной замены старого таймера.
У нас таймер с повышенной точностью реализуется с помощью GetMicrosecondsCount. Его нужно применять осознанно и с понимаем, что он обходится дороже чем GetTickCount. Кроме того, стоимость вызовов GetMicrosecondsCount должна явно учитываться в случаях точных замеров.
Очень легко неправильным использованием таймера и несоблюдением чистоты бенчмарка обмануть самого себя и других.
спс, примерно так и думал после того как представитель MQ писал про уменьшение времени системного таймера ))
поэтому поддерживаю, что не нужно что то менять в этом направлении
кстати хотелось бы узнать, ведутся ли какие то разработки в сторону reflection как в C# ну или хотя бы как в boost ? к примеру сериализацию / десериализацию было бы удобнее реализовывать
можно же просто написать в справке, что GetMicrosecondsCount зависит от локального времени компа и может неадекватно работать при его модификации. А GetTickCount не зависит.
Так и написано в справке: Функция GetMicrosecondCount() возвращает количество микросекунд, прошедших с момента начала работы MQL5-программы.
Так и было мною четко сказано: для замера промежутков времени.
задача микросекундного замера с учетом проблемы тоже решаема, пусть немного коряво. и ее можно решить на нашем уровне и на вашем. видимо придется решать на нашем.
зачем банить-то?
Надо банить.
Во первых, никакой проблемы с замером времени у микросекундного таймера нет. Во вторых - у некоторых прямо зудит, чтобы придумать повод для наброса, а потом держаться до него до последнего.
Еще раз повторю - правила изменились.
Больше никаких оскорблений или "вы должны" не принимаются. Мы проведем зачистку без предупреждений.
Так и написано в справке: Функция GetMicrosecondCount() возвращает количество микросекунд, прошедших с момента начала работы MQL5-программы.
А для функции GetTickCount написано:
Функция GetTickCount() возвращает количество миллисекунд, прошедших с момента старта системы.
Фразы практически идентичны, но одна функция зависит от локального времени, вторая нет. как мы должны об этом догадаться?
А для функции GetTickCount написано:
Фразы практически идентичны, но одна функция зависит от локального времени, вторая нет. как мы должны об этом догадаться?
Таков WinAPI.
Напоминаю про использование фраз "должны" в явном или неявном виде. Использование "метаквотс должен" вместо "просим рассмотреть" теперь неприемлемо.