[Comm] Re: Еще 1 метод неоптимально синхронизировать время

[Oleg N. Kayunov]

Henri Bourbon wrote:

>On 20 Oct 2002  3:53, Oleg N. Kayunov wrote:
>
>>Для синхронизации использую ntpdate (свой ntp-сервер отключаю) при
>>dial-up-е.
>>В соотв. скрипте у меня прописано что-то около двух десятков
>>ntp-серверов (начиная с Московских, ест-нно). Если не удаётся
>>синхронизация с одним скрипт идёт к следующему и т.д.
>>
>
>Непосредственно  по  поводу  вашей проблемы со "сговором NTP-серверов" я
>ответил  отдельным письмом. Здесь же, если позволите, хочу покритиковать
>ваш метод синхронизации времени.
>
>Если  я  правильно  понимаю,  нужно  взять  эти  самые  20 NTP-серверов,
>пообщаться  с  ними  минимальное  время,  установить  время на локальном
>компьютере  и завершить процесс. 
>
    Наверно я Вас неправильно понимаю.
Или я плохо изложил в письме..
Список серверов у меня довольно большой, но процесс синхронизации 
заканчивается на первом же сервере из этого списка, с которым удаётся 
"договориться". К оставшимся уже не обращаюсь.
Как правило заканчивается на первом же (что чаще), или вообще не 
заканчивается (реже) успехом. Что меня и удивило.

>Вероятно, такое большое кол-во серверов
>взято для максимальной надежности и точности установки времени. Практика
>(не  столько  моя  личная, сколько людей, писавших NTP FAQ, а тж. самого
>проф.  D.  Mills,  пишущего  ntpd  )  показывает,  что  увеличение числа
>эталонных  серверов  больше  10  не  улучшает точность. Ну да ладно, это
>мелочь.
>
    Да не нужна мне такая уж точность (хотя и хочется :)  ). А была бы 
нужна - пришлось бы делать что-то типа усреднения;  ничего этого у меня 
нет. Да и к каждому из серверов имело бы ИМХО смысл обратиться по 
крайней мере 3 раза (для оценки стабильности) и т.п.. Ничего этого я не 
делаю.

>
>
>Именно описанное в предыдущем абзаце и делает команда
>ntpd -q
>
>(в отличие от `ntpd` без параметров)
>
>При   этом   работают   весьма   и   весьма   тонкие  алгоритмы  отброса
>"подозрительных"  источников  времени,  отбора  наиболее близких к корню
>синхронизации  (stratum  0) и достоверных источников, а затем нахождению
>некоего  хитрого  средневзвешенного значения времени по всем достоверным
>источникам. Алгоритмы, над которыми проф. Милз работал более 10 лет.
>
    Собираются тут у нас поставить постоянное соединение (относительно 
задёшево). Поставят - начну переходить на ntpd. Тем более -учитывая Ваши 
замечания о свойствах этой программы качественно отличающей (в части 
механизма синхронизации) её от ntpdate. Я-то, грешным делом, полагал, 
что это программы более менее однотипные, только отличающиеся в 
функциях/назначении (одна - демон и может "раздавать" время другим, 
другая - только синхронизирует конкретную машину).

>
>
>На   другой   же   чашке   весов   скрипт,  использующий  алгоритмы, над
>которыми  Олег  Каюнов  работал  пару дней. Скрипт использует дуболомную
>программу   ntpdate  (замечательная,   надо сказать, программа была году
>этак в 1993-м).
>
>Олег,  рекомендую вам попробовать вариант с `ntpd -q`. Не исключено, что
>это  решит  и  проблемы  с  ретрейнами,  к-рые  вы,  по  всей видимости,
>испытываете.  В  ntp.conf  рекомендую  занести  не  более  5-8  наиболее
>надежных  серверов.
>
    Таки сначала надо понять - какие это. Исследовать придётся, однако.

>  Да,  `ntpd -q` отнимает нек-рое время (от секунд до
>пары-тройки-нескольких    минут),    поэтому    при   запуске   вручную,
>интерактивно, имеет смысл набирать что-то типа (для csh, в bash не помню
>как редирект делается):
>
># ntpd -q >& /dev/null &
>


-- 
== В действительности все обстоит совершенно иначе чем на самом деле. ==
	BR, Oleg N. Kayunov.