для интернет-серверов, хоть там bgp, хоть sip, хоть еще что, с избытком хватает синхронизации времени с ntp-серверами stratum1/2. :)

Да, как правило хватает. Так и делаю. Но в большом хозяйстве желательно иметь и опорный источник времени, независимый от Сети.

Если машинки работают под *nix, то штатный ntpd справляется с синхронизацией на ура.

Да, конечно.

Ему просто нужно побольше серверов подсунуть у которых повыше стратум

Тут дело не столько в стратуме, сколько в качестве связи до конкретного сервера и его реальной точности. Под качеством связи я понимаю отсутствие асимметрии, малое расстояние, минимум BGP-переключений по маршруту, незагруженность каналов. Реально нужно 3-4 проверенных надежных сервера. При большем кол-ве ntpd просто парит свой электронный мозг без пользы.

при запуске машины всегда делать ntpdate

Вовсе не обязательно. На практике это редко требуется.

а одна на скайлинке

Это CDMA? Как ntpd справляется в этой ситуации? Можете показать мне "ntpq -pn", "ntpq -c rv"?

CDMA IMT-MC-450 с EVDO

ответы ntpq в будни скину, там на машине внешний ип динамический.

Но однозначно могу сказать, что все работает вполне неплохо, пока не глючит скай, т.е. пока он работает вообще и пока расстояние до одного и того же сервера не пляшет на сотни мс.

Вот, кстати, сейчас тоже со ская работаю, пинги до time.nist.gov

Ответ от 192.43.244.18: число байт=32 время=433мс TTL=50
Ответ от 192.43.244.18: число байт=32 время=450мс TTL=50
Ответ от 192.43.244.18: число байт=32 время=436мс TTL=50
Ответ от 192.43.244.18: число байт=32 время=445мс TTL=50

Хотя задачи у меня не операторского класса, нужно всего лишь собирать логи с 10тка wi-fi точек доступа в деревне... Если будут ошибки, то некритично.

Не знаю, может не совсем в тему, но мне кажется, что когда ответ приходит через 433 мс о какой точности вообще может идти речь? Поступаю намного проще. На 14996 вещает РВМ. Сигналы точного времени присутствуют. Точность частоты по- моему обещают не хуже 12 знаков. Выставляю по несущей раз в год Гиацинт (расстройка не более 1 колебания в 40 секунд, через год- примерно вдвое больше). По нему калибрую всю свою измериловку, от него же при необходимости, запитываю электронные часы. Уход считайте сами- полагаю, что за 100 лет и на секунду не уйдут. А вот собственно привязка ко времени уже зависит от того, насколько точно возьмёте импульс точного времени. И уж поверьте, это время будет минимум на 2 порядка меньше, чем интернетовские 400мс. Да, ещё сигналы точного времени с вещалок по моим наблюдениям можно брать только с Маяка (возможно и с Радио России) и только на ДВ и СВ. На УКВ даже в Москве отставание по- моему порядка 800 мс, а в деревне- до 3 с- лично видел! Про TV вообще молчу.

можно еще пытаться принять DCF-77
Или разориться на вот такой девайс http://www.thinksrs.com/products/PRS10.htm :)
(PRS10 — Low phase noise rubidium oscillator)

Igor 2 wrote:
когда ответ приходит через 433 мс о какой точности вообще может идти речь?
Ээээ... Немедленно начать курить rfc-доки-маны и тп о протоколе ntp до полного просветления! :)

пинги до time.nist.gov

Нафига? Используйте ntp-сервер поближе.

Не знаю, может не совсем в тему, но мне кажется, что когда ответ приходит через 433 мс о какой точности вообще может идти речь?

Такая задержка -- не проблема сама по себе. Протокол NTP расчитан на такие задержки, но в случае симметричного канала. Т.е. неточность будет только в случае асимметрии времени прохождения пакета. Если асимметрия известна, то ее легко компенсировать в конфиге. Если нет, то NTP не годится. Нужен GPS или другой источник точного времени.

На 14996 вещает РВМ.

Как бы запитать этим сигналом ntpd?

dimssПод качеством связи я понимаю отсутствие асимметрии
А есть возможность оценить асимметрию канала, учитывая, что доступна машина только с этой стороны, а оттуда пропинговаться возможности нет?

AlexUT4У всех GPS модулей есть специальный выход PPS - один импульс в секунду.
Я правильно понял, что такой выход есть только у GPS модулей, а с бытовых GPS-приемников снять этот сигнал нельзя?

dimss. К сожалению, как запитать этим сигналом ntpd я не знаю, так как не знаю, что это такое. А часы у меня когда мне надо идут с расхождением с эталоном заметно менее 10 мс (не сомневаюсь, что если понадобится сделаю точнее, пока не надо). Точность хода- по РВМ (по состоянию на 1980 год- 5*10-11, думаю, что сейчас выше) плюс расстройка Гиацинта (0.025 Гц на частоте 14996000 Гц). В интернете я не спец, но с него брать точное время по- моему бред. Возможно где- то и по- другому, но у меня время пингования порой отличается в разы и предсказать, какое оно будет через какой- то промежуток времени проблематично.

2Igor 2: Тут суть не во времени до сервера, а его стабильности. Если знаем за сколько доходит пакет, то можем принять пакет с меткой точного времени и вычесть задержку на распространение. Это если в простейшем представлении. Фактически ntpd намного более интеллектуальная система, которая может работать даже если пакетики летают не за постоянное время.

2dimss: Это я для прмера привел самый популярный... ;-) Фактически забираю с серверов более близких.

По прикручиванию gps к ntpd, гляньте тут

http://www.google.com/search?hl=en&lr=&client=opera&rls=ru&q=configuring+ntpd+pps&btnG=Search

сам не читал, но возможно что-то полезное будет.

Dimik Если бы, да кабы оно бы было... Я же и пишу (см. выше), что у меня время пингования изменяется в разы. Попробуйте мне объяснить, как можно установить точное время при хаотичном изменении пингования от 100 до 1000мс. Среднее время вычислить? Считаю, что нельзя это сделать. Попробуйте переубедить.

А есть возможность оценить асимметрию канала

В некоторых случаях помогает программа tracepath. Она показывает асимметрию с точки зрения маршрутизации.

В интернете я не спец, но с него брать точное время по- моему бред.

Не бред, а нормальное явление, если доступен качественный (с точки зрения ntp) канал и есть расположенный недалеко точный сервер. В такой ситуации расхождение в единицы миллисекунд в порядке вещей.

Попробуйте мне объяснить, как можно установить точное время при хаотичном изменении пингования от 100 до 1000мс.

Видимо, никак. Потому что такой канал, скорее всего, имеет большую и при этом хаотическую асимметрию.

Интересно, при чем тут BGP приплели?... А я пользуюсь близкими ntp серверами - релкомовским и ростелекомовским.

Интересно, при чем тут BGP приплели?

При том, что BGP определяет маршрут пакетов между AS. Практически неизбежное зло -- асимметрия маршрутов, вызванная несогласованностью политик маршрутизации различных AS. NTP не переваривает асимметрию. Кроме того, частые переключения BGP на пути NTP-пакетов приводят частому изменению времени прохождения пакетов, а значит, ntpd вынужден чаще пересматривать свое отношение к миру.

А как пример я привел BGP еще и потому, что у меня происходит регистрация некоторых BGP-событий в числе прочих, и там мне нужно точно знать, _когда_ и что произошло.

dimss
Какая, простите, ассиметрия? В правильном стеке IP пакет пришедший по одному маршруту, туда и уйдет ответ на него. По поводу частой смены маршрутов, то надо дергать апстримов за такие плавающие дела. Естественно, что навязывать политику маршрутизации соседу не получится, но можно всегда договориться.

А как пример я привел BGP еще и потому, что у меня происходит регистрация некоторых BGP-событий в числе прочих, и там мне нужно точно знать, _когда_ и что произошло.

Пользуйтесь ближними серверами, хотя бы российскими, поскольку маршруты у нас меняются редко. Да и зачем для журналирования такая точность? У меня вообще все сервера синхронизируются раз в сутки и уход там - доли секунды - это не критически вообще. При необходимости я, конечно же могу взять, практически безупречную, синхронизацию из D каналов Ростелекома, Голдентелекома (телефония), но оно мне не надо - с точностью до долей секунд видеть, что у меня, к примеру, "порвалась" BGP сессия с кем-то и пр.
То же самое касается и систем радиосвязи, которые мы имеем - особая точность времени просто ни к чему.

Какая, простите, ассиметрия? В правильном стеке IP пакет пришедший по одному маршруту, туда и уйдет ответ на него.

Нет, это совершенно не зависит от стека IP. Маршруты туда и обратно вообще не связаны ничем, кроме наличия каналов и доброй воли сетевых инженеров. Асимметрия трафика на просторах Европы и Америки -- обычное дело. Конечно, все стараются ее минимизировать, но она все равно есть в некотором проценте случаев. Потому что идеально согласовать политики всех АС нереально с организационной точки зрения, и все время где-то какие-то каналы рвутся и переключаются.

Пользуйтесь ближними серверами

Для меня это Европа. До России, как правило, намного дальше в смысле миллисекунд и хопов.

Мы пробовали использовать в качестве stratum 1 GPS-приемник кластера Motorola Canopy. Получилось смешно. ntpd быстро отказывался верить времени этого приемника, и продолжал пользоваться сервером Stratum 2 через Инет. Оказалось, что Motorola Canopy объявляет себя как Stratum 1 (так и должно быть), но время выдает с точностью до секунды. В результате имеем ошибку до полусекунды. ntpd это дело просекает и отказывается верить такому источнику.

Интересно, глонассовцы будут выпускать нечто подобное gps-time для получения точного времени?

Уже выпускают. Например, контора "Время Ч". У них кроме прочего есть рэковый NTP-сервер с поддержкой GPS и Глонасс. Причем они говорят, что можно его сделать так, что будет работать только с Глонасс, если нужно.

Если бы, да кабы оно бы было... Я же и пишу (см. выше), что у меня время пингования изменяется в разы. Попробуйте мне объяснить, как можно установить точное время при хаотичном изменении пингования от 100 до 1000мс.

Сменив провайдера... Даже самые убогие московские районные сети дают задержки в первой 10тке мс, при очень маленькой дисперсии.

Считаю, что нельзя это сделать. Попробуйте переубедить.

Не имею никакой нужды Вас переубеждать. Мы обсуждаем проблемы синхронизации в вычислительных сетях, а не скрещивание настенных ходиков с Гиацинтом и КВшными дуделками.

В интернете я не спец, но с него брать точное время по- моему бред.

Век живи - век учись...

dimsswrote:
Уже выпускают. Например, контора "Время Ч". У них кроме прочего есть рэковый NTP-сервер с поддержкой GPS и Глонасс. Причем они говорят, что можно его сделать так, что будет работать только с Глонасс, если нужно.

И цена от самолета, да.

Точность времени и частоты по GPS высокая, вот тут можно посмотреть усредненные данные за 24 часа , за 14.01.2007.
http://gps.nist.gov/scripts/onewaygps.exe

Данные что приводились в одном из постов, про отставание на сколько то там минут, очень странные.
Как такое может быть? Вот усредненные данные за 24 часа.

Hours 24
Mean Time Offset (ns) 32.90
Range (ns) 4.36
Frequency Offset -2.94 x 10-14
Confidence (r) -0.59

И цена от самолета, да.


Вот что они мне написали:

Уважаемый Дмитрий!

Навигационная система выбирается автоматически, однако,
по желанию заказчика мы можем отменить автоматический выбор и назначить
любую из систем.

Цена прибора 166600 руб.

Это на наши ~3300 LVL. По цене как десять недорогих компов :) То ли контора специальная, под "госзаказы" и "сертификацию", то ли товар совсем уж штучный.

Но я думаю, что по мере оживления Глонасс пользователей станет больше, спрос увеличится, цена снизится.

К слову, ни один из европейских производителей аппаратных NTP-серверов мне так и не ответил на вопрос о цене :) Похоже, что подобная техника либо совсем штучная, либо под большие проекты, либо... негласно попадает под "спецуху".

Ну нет уж :) Проще тогда пойти на поклон к http://www.moba-time.ru/products/servers/lts.php По-крайней мере, LTS+GPS стоит дешевле, в районе 1300 Эвро.
Заодно можно подцепить приемник радиосингала DCF-77, к нам ближайшая станция в Германии.
Или взять для автономного источника вот это: http://www.thinksrs.com/products/PRS10.htm
Выйдет всяко дешевле наших госбандитов с большой дороги.

Да, про спрос на ГЛОНАСС. ДУмаю, его будут вводить насильно, мол, хтите лицензию -- пользуйте наше, так что сильного падения цен тут не будет.

Да, про спрос на ГЛОНАСС. ДУмаю, его будут вводить насильно

И правильно.

так что сильного падения цен тут не будет.

Почему же? Будет, но не в следствие "конкуренции" Глонасс и GPS, а по причине появления бОльшего количества поставщиков Глонасс и снижения себестоимости при большом объеме.

Вопрос в том, что "насилие" должно быть грамотно применено.

dimss wrote:
Почему же? Будет, но не в следствие "конкуренции" Глонасс и GPS, а по причине появления бОльшего количества поставщиков Глонасс и снижения себестоимости при большом объеме.

Ой, что-то мне в это с трудом верится.
Ибо поставщик должен будет получить кучу недешевых лицензий и пройти сертификацию кое-где.

Есть программа OziExplorer Ce для КПК, так там часы синхронизируются при помощи GPS автоматически. Пробовал не только время неправильное ставить, но и год с месяцем и датой менял. Этот процесс после нахождения спутников занимает секунд 5.
Только что синхронизировал ПК через time.windows.com и посмотрел на расхождения, которые составили примерно 1,5 секунды. Что из этого точнее не знаю, толи GPS отстаёт (в чём лично я сомневаюсь), толи сервер в инете спешит.

У time.windows.com вообще-то stratum 5:

$ ntpdate -q time.windows.com
server 207.46.130.100, stratum 5

Ну и для примера:

$ ntpdate -q ntp0.zenon.net
server 195.2.64.5, stratum 1

$ ntpq -p ntp0.zenon.net
remote refid st t when poll reach delay offset jitter
==============================================================================
*GPS_PALISADE(0) .GPS. 0 - 43 128 377 0.000 -0.417 0.611
+ntp2.gbg.netnod .PPS. 1 u 54 128 377 32.620 0.339 0.152
+ntp1-rz.rrze.un .DCFp. 1 u 42 128 377 52.997 0.020 0.157
+vega.cbk.poznan .PPS. 1 u 1 128 377 53.344 0.403 4.114

А кто-нибудь принимает в Москве сигнал от DCF-77 ? Я как не пробовал, не удалось.

Igor 2
Среднее время вычислить? Считаю, что нельзя это сделать. Попробуйте переубедить.

Пробуем... ;)

Когда NTP-клиент отправляет запрос на сервер, он указывает в поле VN свою версию, в поле Mode – тип своей работы, а в поле Originate – время отправления этого запроса (по своим часам). Сервер, примяв запрос, заполняет в NTP-пакете все поля, скопировав в поле Originate значение, пришедшее в запросе. Таким образом, у клиента, когда к нему приходит ответ от сервера, имеются четыре значения времени: org (время отправки запроса), rec (время получения запроса сервером), xmt (время отправки ответа сервером) – из NTP-пакета и loc (время получения ответа) – по показаниям локальных часов в момент прихода ответа. При этом значения org и loc соответствуют показаниям часов локальной машины, а rec и xmt – показаниям часов сервера.

Выполняемая затем обработка этих значений аналогична действиям английского джентльмена из старой задачи Рэймонда М. Смаллиана (1978): «У одного человека не было наручных часов, но зато дома висели точные настенные часы, которые он иногда забывал заводить. Однажды, забывв очередной раз завести часы, он отправился в гости к своему другу, провел у того вечер, а вернувшись домой, сумел правильно поставить часы. Каким образом ему удалось это сделать, если время в пути заранее известно не было?» Ответ таков: «Выходя из дома, человек заводит часы и запоминает, в каком положении находятся стрелки. Придя к другу и уходя из гостей, он отмечает время своего прихода и ухода. Это позволяет ему узнать, сколько он находился в гостях. Вернувшись домой и взглянув на часы, человек определяет продолжительность своего отсутствия. Вычитая из этого времени то время, которое он провел в гостях, человек узнает время, затраченное на дорогу туда и обратно. Прибавив ко времени выхода из гостей половину времени, затраченного на дорогу, он получает возможность узнать время прихода домой и перевести соответствующим образом стрелки своих часов.» (http://ntl.narod.ru/logic/smullyan/name/p2.html#13)

Касательно РВМ, то она вещает не только на 14996 но и на 4996 и 9996 кГц.
Принимается весьма не плохо. И действительно было бы очень неплохо завести сигнал на ntpd, но как?