[Comm] åÝÅ 1 ÍÅÔÏÄ ÎÅÏÐÔÉÍÁÌØÎÏ ÓÉÎÈÒÏÎÉÚÉÒÏ×ÁÔØ ×ÒÅÍÑ

[Henri Bourbon <useperl@fastmail.fm>]

On 21 Oct 2002  17:04, Oleg N. Kayunov wrote:

> Henri Bourbon wrote:

>>On 20 Oct 2002  3:53, Oleg N. Kayunov wrote:

>>>Для синхронизации использую ntpdate (свой ntp-сервер отключаю) при
>>>dial-up-е.
>>>В соотв. скрипте у меня прописано что-то около двух десятков
>>>ntp-серверов (начиная с Московских, ест-нно). Если не удаётся
>>>синхронизация с одним скрипт идёт к следующему и т.д.

>>Если  я  правильно  понимаю,  нужно  взять  эти  самые  20 NTP-серверов,
>>пообщаться  с  ними  минимальное  время,  установить  время на локальном
>>компьютере  и завершить процесс. 

>     Наверно я Вас неправильно понимаю.
> Или я плохо изложил в письме..

Вы все вполне понятно изложили.

> Список серверов у меня довольно большой, но процесс синхронизации 
> заканчивается на первом же сервере из этого списка, с которым удаётся 
> "договориться". К оставшимся уже не обращаюсь.
> Как правило заканчивается на первом же (что чаще), или вообще не 
> заканчивается (реже) успехом. Что меня и удивило.

Я  прекрасно  понял из вашего предыдущего письма, Олег, что *именно* вас
удивило.  Повторяю:  по поводу странного поведения "или синхронизируется
на  1-м же сервере, или вообще не синхронизируется" читайте мое письмо с
темой
[Comm] Как retrain приводит к "сговору" NTP, DNS и прочих серверов
Если  коротко,  то  виноват  ваш  модем,  гнилая телефонная линия, модем
провайдера  и  бритва/электродрель  соседа,  а  не  какие  бы то ни было
серверы в Интернет, будь то NTP, DNS или Real Audio серверы.
Здесь   же,   в   этой  подветке, я пытаюсь вас убедить, что (обычно) не
нужно писать никаких скриптов, тем более, использующих ntpdate . То, что
делает ваш скрипт, делает, причем грамотнее, `ntpd -q` .

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

... зато все это делает ntpd -q     ;-)

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

Олег,  кажется,  здесь вы не понимаете очень существенный момент. `ntpd`
запустит  демон,  работающий  постоянно,  и,  в  силу своего "non-robust
design",  требующий  постоянного  соединения.
НАОБОРОТ,  `ntpd   -q`  запустит  Умный  Вариант  ntpdate,  Который  3-4
раза    Соединится   с  Каждым из Серверов, Вычислит Поправку, Переведет
Часы и --  И! 8-)  -- Завершит Свою Работу.
`ntpd -q` -- это Прямая Замена ntpdate.
Проф.  Миллз  собирается  вообще  убрать  ntpdate  из поставки ntpd. Как
рудимент и атавизм. Туды его (ntpdate) в качель.

>>Олег,  рекомендую вам попробовать вариант с `ntpd -q`. Не исключено, что
>>это  решит  и  проблемы  с  ретрейнами,  к-рые  вы,  по  всей видимости,
>>испытываете.  В  ntp.conf  рекомендую  занести  не  более  5-8  наиболее
>>надежных  серверов.

>     Таки сначала надо понять - какие это. Исследовать придётся, однако.

При  наличии  соединения с Сетью это делается элементарно. Разумеется, с
помощью  того  же ntpd :-) Выставили poll много большим среднего времени
ретрейна  (скажем,  minpoll  9 maxpoll 9 даст poll~= 8 минут), подождали
8*poll  (чуть больше часа в случае 8 минут), смотрим (с помощью ntpq -p)
на  регистры  доступности. Кто не был доступен хоть раз (reachability !=
377   ),  тот  и есть кандидат в неблагонадежные. Реально лишь публичные
"серверы"  (я  бы  эти  полулежащие  дрова  так  не  назвал)  в  Дубне и
Черноголовке стоит убрать из ntp.conf .
Я  догадываюсь,  Олег,  что  это  не самая ваша большая проблема, есть и
более  важные.  Суть  в  том, что "исследовать" не нужно, точнее, на это
уйдет  гораздо меньше времени (времени работы вашего мозга, не wallclock
time (-: ), чем у меня ушло на 3 письма в этой ветке.

-- 
HB