Ну я об этом и говорю. Первый вызов происходит до синхронизации, а второй - после синхронизации. Разница получится равной: фактическое количество микросекунд + поправка синхронизации.
Ну я об этом и говорю. Первый вызов происходит до синхронизации, а второй - после синхронизации. Разница получится равной: фактическое количество микросекунд + поправка синхронизации.
Теперь скажите мне вероятность корректировки времени между двумя вызовами GetMicrofsecondsCount?
Если Вы действительно меряете микросекунды, то вероятность практически равна 0.
А вы меряете микросекунды на секундных и более интервалах? Зачем? Сфероконь в вакууме?
Вы ошибаетесь. Я же вот здесь специально привёл код с использованием WinApi. Запустите, поменяйте часы в процессе, и посмотрите на результат.
Не очень понятно, как с вами вести какой-либо диалог, если ваши аргументы основаны на домыслах. И даже не считаете нужным ознакомиться с ходом обсуждения темы.
Это вы понятия не имеете о поднятой проблеме.
Как я и сказал, неожиданная смена времени будет убивать код, завязанный на точный контроль времени вне зависимости от используемых функций.
Теперь скажите мне вероятность корректировки времени между двумя вызовами GetMicrofsecondsCount?
Если Вы действительно меряете микросекунды, то вероятность практически равна 0.
А вы меряете микросекунды на секундных и более интервалах? Зачем? Сфероконь в вакууме?
Я уже ответил, эта вероятность зависит от периода синхронизации. Чем он короче, тем чаще будем попадать на сдвижку, т.е. выше вероятность. А также от расстояния между соседними замерами. Чем оно длиннее, тем чаще будем попадать на сдвижку. Т.е. вероятность рассчитывается на основе этих двух параметров, а не просто пальцем в небо.
И почему вы пишете сразу про секундные интервалы? А миллисекундные интервалы? Например всё что менее 16 мс можно замерить только данной функций. И даже 16-30 миллисекунд тоже надо мерить данной функций, иначе погрешность будет слишком велика.
Если вам кажется что это мелочи и ими можно пренебречь, то это сугубо ваше личное мнение. Ранее мы тут уговорили о штатной системной функции QueryPerformanceCounter, которая работает как надо, без всяких сдвижек. Её наверное придумали не просто так. И кстати вот здесь Ренат почему-то заявил:
У нас так и считаются микросекунды
Хотя по факту совсем не так. Речь шла про QueryPerformanceCounter
Напоминаю про использование фраз "должны" в явном или неявном виде. Использование "метаквотс должен" вместо "просим рассмотреть" теперь неприемлемо.
Прошу рассмотреть возможность допущения, что чаще всего чтение между строк не имеет никакого отношения к тому, что пишет собеседник.
Реальные баг-репорты с оказанием помощи на форуме и набрасывание на MQ - вещи несовместимые. Сложно представить человека, который постоянно переобувается в хейтера и обратно.
IS 0 13:32:55.239 Trades '11391209': accepted exchange buy 1.00 AFKS at market
DM 0 13:33:07.896 Trades '11391209': deal #265475900 buy 1.00 AFKS at 9.095 done (based on order #284425784)
OD 0 13:33:07.898 Trades '11391209': order #284425784 buy 1.00 / 1.00 AFKS at 9.095 done in 12757.608 ms
Друзья, не подскажете, к кому обратиться за советом - хочу понять, как можно работать на разнице цен на один и тот же продукт на разных биржах - я новичок в этом деле, хочу разобраться. Буду благодарен за любой совет - может быть, нужно написать в другую ветку?
У меня есть возможность доступа к нескольким зарубежным биржам, но нет понимания, как это все работает
Вы вопрос точно весь прочитали?
...между двумя вызовами GetMicrosecondsCount...
Ну я об этом и говорю. Первый вызов происходит до синхронизации, а второй - после синхронизации. Разница получится равной: фактическое количество микросекунд + поправка синхронизации.
Ну я об этом и говорю. Первый вызов происходит до синхронизации, а второй - после синхронизации. Разница получится равной: фактическое количество микросекунд + поправка синхронизации.
Теперь скажите мне вероятность корректировки времени между двумя вызовами GetMicrofsecondsCount?
Если Вы действительно меряете микросекунды, то вероятность практически равна 0.
А вы меряете микросекунды на секундных и более интервалах? Зачем? Сфероконь в вакууме?
Вы ошибаетесь. Я же вот здесь специально привёл код с использованием WinApi. Запустите, поменяйте часы в процессе, и посмотрите на результат.
Не очень понятно, как с вами вести какой-либо диалог, если ваши аргументы основаны на домыслах. И даже не считаете нужным ознакомиться с ходом обсуждения темы.
Теперь скажите мне вероятность корректировки времени между двумя вызовами GetMicrofsecondsCount?
Если Вы действительно меряете микросекунды, то вероятность практически равна 0.
А вы меряете микросекунды на секундных и более интервалах? Зачем? Сфероконь в вакууме?
Я уже ответил, эта вероятность зависит от периода синхронизации. Чем он короче, тем чаще будем попадать на сдвижку, т.е. выше вероятность. А также от расстояния между соседними замерами. Чем оно длиннее, тем чаще будем попадать на сдвижку. Т.е. вероятность рассчитывается на основе этих двух параметров, а не просто пальцем в небо.
И почему вы пишете сразу про секундные интервалы? А миллисекундные интервалы? Например всё что менее 16 мс можно замерить только данной функций. И даже 16-30 миллисекунд тоже надо мерить данной функций, иначе погрешность будет слишком велика.
Если вам кажется что это мелочи и ими можно пренебречь, то это сугубо ваше личное мнение. Ранее мы тут уговорили о штатной системной функции QueryPerformanceCounter, которая работает как надо, без всяких сдвижек. Её наверное придумали не просто так. И кстати вот здесь Ренат почему-то заявил:
У нас так и считаются микросекунды
Хотя по факту совсем не так. Речь шла про QueryPerformanceCounter
Это вы понятия не имеете о поднятой проблеме.
В QueryPerformanceCounter нет никакой смены времени. О чём вы? Вы запускали тот код, ссылку на который я вам дал?
После проверки машины исполнения MQL5 кода оказалось, что у нас работала гибридная схема замера в GetMicrosecondCount:
Такой код появился из-за попытки уменьшить системный оверхед на вызове замера времени. Один из разработчиков перестарался.
Лично я и Слава были уверены, что работает чистый QueryPerformanceCounter. И такой код был. Но ошиблись из-за наличия гибридной модели.
Сейчас будет работать исключительно QueryPerformanceFrequency + QueryPerformanceCounter.
Итогом: да, мы облажались как с реализацией фукции GetMicrosecondCount, так и с защитой ее поведения.
Мы со Славой приносим свои извинения!Напоминаю про использование фраз "должны" в явном или неявном виде. Использование "метаквотс должен" вместо "просим рассмотреть" теперь неприемлемо.
Прошу рассмотреть возможность допущения, что чаще всего чтение между строк не имеет никакого отношения к тому, что пишет собеседник.
Реальные баг-репорты с оказанием помощи на форуме и набрасывание на MQ - вещи несовместимые. Сложно представить человека, который постоянно переобувается в хейтера и обратно.
IS 0 13:32:55.239 Trades '11391209': accepted exchange buy 1.00 AFKS at market DM 0 13:33:07.896 Trades '11391209': deal #265475900 buy 1.00 AFKS at 9.095 done (based on order #284425784) OD 0 13:33:07.898 Trades '11391209': order #284425784 buy 1.00 / 1.00 AFKS at 9.095 done in 12757.608 msДрузья, не подскажете, к кому обратиться за советом - хочу понять, как можно работать на разнице цен на один и тот же продукт на разных биржах - я новичок в этом деле, хочу разобраться. Буду благодарен за любой совет - может быть, нужно написать в другую ветку?
У меня есть возможность доступа к нескольким зарубежным биржам, но нет понимания, как это все работает