Получить системное время
Нет никаких способов выставить часы компьютера с такой точностью. А с неточных часов, естественно, нельзя получить точное время.
Может, имеется в виду не абсолютное, а относительное время, т.е. измерение интервалов с указанной точностью?
Дело в том что нам известно с какой точностью работает таймер.
65536/1193181=0,054925447186973309162650092483873 с
Так что читаем время из ячейки. 40h:60h(пишу по памяти) умножаем на константу.
Плюс считываем из таймера сколько прошло тиков.
Или использовать RDTSC предварительно померив частот через PIT.
PS
В теме "Рандом на асме" было написано про часы CMOS, от которых якобы можно получать прерывания до 1000 раз в сек. Может, это как-то может помочь? Если так, то как (поближе к конкретике) это сделать?
Так что после уточнения задачи заявляю определенно: это невозможно.
В компьютере несколько генераторов.
Основной 14.31818 МГц на основе него получают все многообразие частот.
Вообще рекомендован генератор именно с этой частотой, но может быть и 14,318 МГц. Правда, все рассчитана на первой.
Второй генератор имеет частоту 32,768 КГц и применяется в часах реального времени RTC. :)
Точность. Что определяет точность? Точность определяет число значащих цифр в числе и чем их больше, тем точнее число. Точнее таймер
0,5/1431818=0,000000349=0,35*10^-6 это значит, что ошибка будет проявляться через 1 миллионов итераций
0,5/14318=0,35*10^-4 при такой точности ошибка будет заметна при 10 тыс. итераций
0,5/32768=0,15*10^-4 аналогично.
Цифры цифрами, но что они значат в реалии? В стуках 60*60*24=86 400 секунд
Это цифра превышает 10 тыс. Это значит что ошибка в сутках для RTC
,будет составлять 0,15*10^-4*86400=1.32 c.
Тут было выбрано абсолютная ошибка 0,5 из расчета того, что таймер генерирует с заданной частотой. На самом деле это не совсем так погрешность любого кварцевого генератора составляет 30-50 миллионных, для более точных на порядок.
И того имеем погрешность
30*10^-6*86400=2.6 с
50*10^-6*86400=4.32 с
Практика показывает, что оно так и есть ошибка порядка 3,5-4,5 с
Ошибка носит систематический характер. А также зависит от температуры.
А предложенный метод Фантома только позволяет повысить дискретизацию. Что полезно, но точность не повысится.
Служба точного времени в Интернет посылает сигналы 1 раз в секунду, и, учитывая время прохождения пакетов через цепочку серверов, с большей частотой посылать нет смысла.
PS. Сейчас проверил: пинг до одного из серверов точного времени идет около 500 мс, т.е. о точности 5 мс говорить не приходится.
Если сервер пошлет 1000 пакетов и усреднить время то точность будет, та что надо 5 мс
Надо почитать подробнее как они там борятся.
У меня до time1.free.net пинг колеблются 10-65мс вообще жуть никогда такого пинга не видел обычно устойчивый, а тут такой разброс.
А вообще это у вашего провайдера проблемы. У меня пинг редко когда больше 300мс. :P
Хорошо, допустим ты узгнал, что время прохождения ping 497 мс. Но это сумма туда и обратно. Как ты предлагаешь отдельно оценить, сколько времени он идет туда, и сколько обратно?
А вообще это у вашего провайдера проблемы. У меня пинг редко когда больше 300мс. :P
Вопрос не в том, что конкретно у тебя и что конкретно у меня. Вопрос в том, что программа должна работать У ЛЮБОГО. А при этих условиях обеспечить точность установки системных частов через Интернет с точностью лучше 5 мс невозможно.
Т.е. задача в предложенной постановке неразрешима. Нужно либо менять постановку, либо отказываться от попыток ее решения.
Что касается NTP v4 то там предлагается записывать время как на машине отсылать на сервер сервер шлет ответ и снова клиент шлет время и снова сервер шлет ответ. И 5 нам известно время прихода пакета к клиенту.
Откуда легко вычисляется сколько пакет шел туда сколько обратно.
А вообще в RFC1305 предложен какой-то метод фильтрации так что возможно точность будет выше чем просто усреднение.
Пусть, для определенности, от сервера к клиенту пакет идет 100 мс, а обратно - 200. Но нам это неизвестно. Как синхронизировать часы на клиенте с сервером?
Посылаем запрос сервер его принимает записывает GT1:=GT отправляет.
Клиент принимает пакет смотрит свое время LT1:=LT;
Разница LT1-GT1=время в пути+рассинхронизация. Рассинхронизация величина постоянная. Время в пути имеет случайный характер но подлежит определенным законом. Если просто усреднить то мы можем получить среднее время в пути. Но на самом деле время затраченное в пути имеет квантование те. Разброс состоит из набора некоторых фиксированных чисел. Остается вычислить эти тем самым разделить на составляющие и понять какое из них является временем рассинхронизации. Тут надо анализировать но уверен что есть временные интервалы в которых возможна синхронизация.
Хотя если принять среднее время туда и обратно одинаковым то тогда легко убирается. +рассинхронизация+время в пути , а в обратную -рассинхронизация+время в пути
То достаточно вычесть.
Pavia, извини, но выглядит это довольно забавно, хотя может быть и правильно.
Рассинхронизация величина постоянная.
В свое время пытался написать динамическую сетевую игрушку. Проблема возникла как раз с синхронизацией клиента и сервера. Когда выяснил, что часы на клиенте и сервере идут с разной скоростью (т.е. как раз не выполняется условие постоянства величины синхронизаци), я это дело забросил.
Так что предположение, конечно, хорошее, но на практике, увы в общем случае не выполняющееся.
Ну да лажно.
Предположим ПОКА для простоты, что это условие выполняется.
[Вопрос квантования, конечно, интересен, но, опять же, предположим для простоты, что квантования нет (либо шаг квантования очень мал).
Надо же нам хоть как-то сдвинуться с места.
Хотя если принять среднее время туда и обратно одинаковым то тогда легко убирается. +рассинхронизация+время в пути , а в обратную -рассинхронизация+время в пути
То достаточно вычесть.
Нет, ну это просто несерьезно!
Я могу согласиться, что рассинхронизация - величина постоянная, я могу согласить даже с тем, что нет разброса, но я явно оговорил в вопросе, что время туда и обратно различаются.
Итак, что имеем: вычисленное нами "сренее" время в пути 150 мс, что на 50 мс отличается от того, что имеется по условию задачи.
Вывод: предложенный метод дает на данном конкретном примере ошибку в 50 мс, что на порядок больше допустимых 5 мс.
МЕТОД НЕ РАБОТАЕТ.
Ethernet оптика является дву направленными каналами, но обработка идет в общем буфере на роутерах. Так что задержка должна быть одинаковой. Единственное что есть разброс. Но тут используем усреднение чтобы устранить ошибку вызванную разбросом задержек. Для таких систем вопрос решен.
Единственный вариант это спутниковая связь когда прием идет одним каналом передача другим. Но такими узлами связи можно пренебречь так как их мало.
Но раз интересно будем думать.
Время рассинхронизации пусть et.
3 неизвестных 2 уравнения не решаемо.
et+за1=T1
-et+за2=T2
Нужно как-то до определить условия. При маленькой дискретизации у нас и расхождение будет маленькое. А при большой большое. Поэтому я и предлагаю исследовать этот момент, а не отбрасывать. Мы сможем примерно оценить за1 и за2 пусти и с ошибкой. Но если мы сможем уменьшить их на парядок то уже будет хорошо. Значит при следующей итерации мы сможем приблизится если конечно мы точно сможем определить дискретизацию. Надо думать.
Соображения два: общее и частное.
Общее: пока не доказано, что одинаковое, следует считать разным.
Частное: В общем случае маршруты туда и обратно будут разными. Разные маршруты - разное время.
Ethernet оптика является дву направленными каналами, но обработка идет в общем буфере на роутерах. Так что задержка должна быть одинаковой.
При обязательном условии, что маршрут тот же самый. Но маршрутизация происходит независимо, - обратный маршрут не повторяет прямой.
Тоже не все так гладко. Пример с изменяющейся со временем рассинхронизацией я уже приводил.
Кроме того, нагрузка может меняться со временем, а вместе с ней - и величины задержек. Пока мы статистически пытаемся определить среднюю величину, возросла нагрузка и вычисленная нами средняя уже стабильно меньше средней в настоящий момент времени.
Единственный вариант это спутниковая связь когда прием идет одним каналом передача другим. Но такими узлами связи можно пренебречь так как их мало.
Это общий случай. И именно на него и следует ориентироваться.
Кроме того, этот случай по совместительству является наихудшим, поэтому необходимо ориентироваться именно на него.
Но раз интересно будем думать.
Время рассинхронизации пусть et.
3 неизвестных 2 уравнения не решаемо.
et+за1=T1
-et+за2=T2
Нужно как-то до определить условия. При маленькой дискретизации у нас и расхождение будет маленькое. А при большой большое. Поэтому я и предлагаю исследовать этот момент, а не отбрасывать. Мы сможем примерно оценить за1 и за2 пусти и с ошибкой. Но если мы сможем уменьшить их на парядок то уже будет хорошо. Значит при следующей итерации мы сможем приблизится если конечно мы точно сможем определить дискретизацию. Надо думать.
А скакой стати у нас разброс зависит от дискретизации? Что, например, мешает пакету идти каждый раз другим путем?
Мне кажется, задача неразрешима в принципе. Как парадокс относительности одновременности в теории относительности. Там тоже для достаточно широкого спектра условий принципиально невозможно сказать, которое из двух событий произошло раньше, а какое - позже.
И еще. Подсчитывать статистику далеко не так просто, как это может показаться на первый взгляд. Нужно предусмотреть, чтобы исследования были статистически достоверны с учетом разброса:
- по времени суток,
- по дню недели,
- по сезону,
- по расположению (географическое место, оператор и т.д.) сервера,
- по расположению клиента.
А в общем, я думаю, что для обеспечения на компе точного времени необходим некий дополнительный девайс, специально для этого сконструированный и пользующийся другой передающей средой, нежели Интернет.
Т.е. проблема аппаратная, а не программная.
организация сети мешает. Маршрутизатор хранит маршрут если он не знает то шлет во все но организация у нас в виде дерева, а не звездно образная. Отсюда имеем фиксированный маршрут.
Не верю я в это время прихода пакета не фиксированное а имеет разброс. Так что в ваши измерения я не верю скорее уж просто из-за этого было разное время доставки пакетов вот время и скакало.
PS. Я не говорю о 100% синхронизации, а только о той которая в определенных случаях гарантирует достаточную точность в нашем случае пусть до 1-0.1 мс.
В идеальном случии архиваторов не бывают а они есть так и тут. Не надо отталкиваться от домыслов, а надо отталкиваться от реалий.
Дальше уж пусть организовывают нормальную сеть. Чтобы дать возможность. А особенности сети я пытаюсь учесть.
Ведь он вычисляет координаты именно исходя из времени распространения ЭМ-сигнала от каждого из спутников. Если погрешность измерения координат 30 м, это соответствует неопределенности во времени 0.1 мкс. Правда, между моментом приема данных соспутников и их выдачей наружу прибор некоторое время проводит вычисления, но это - систематическая ошибка, и ее величина должна быть близка к константе.
при синронизации по интернету каждый час ошибка не будет превышать сотен миллисекунд . в пределах секунды собственные часы компа вполне равномерно идут . а для высокой точности GPS карточку ставь .