[Comm] Сговор NTP-серверов

[Comm] Сговор NTP-серверов

[Oleg N. Kayunov]

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

     Странность в следующем - если синхронизация таки не удаётся с первым
же сервером (какой-то из zenon-ов), то она, в подавляющем большинстве
случаев, не удаётся и со всеми остальными.
     Сабж, однако.
     Но не всегда. Достаточно редко, но бывает, что обломившись на первом
сервере, синхронизация таки проходит с одним из следующих в списке. Т.е.
дело, похоже, не в особенностях того или иного сеанса dial-up-а, как
такового.Да и повтор, в рамках того же dial-up сеанса, но через 
некоторое время, иногда даёт успешный результат.

     Master, регулярные updates (но  не из Сизифа), ntp-4.1.1-alt3

-- 
== Мало видел -многому дивишся: видишь верблюда - думаешь: "У лошади 
вспухла спмна". ==
	BR, Oleg N. Kayunov.

Re: [Comm] óÇÏ×ÏÒ NTP-ÓÅÒ×ÅÒÏ×

[ASA]

Hello Oleg,

Sunday, October 20, 2002, 4:53:59 AM, you wrote:

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

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

ONK>      Сабж, однако.
ONK>      Но не всегда. Достаточно редко, но бывает, что обломившись на первом
ONK> сервере, синхронизация таки проходит с одним из следующих в списке. Т.е.
ONK> дело, похоже, не в особенностях того или иного сеанса dial-up-а, как
ONK> такового.Да и повтор, в рамках того же dial-up сеанса, но через 
ONK> некоторое время, иногда даёт успешный результат.

Как я догадываюсь, ntp идет первым действием сразу после
дозвона? Может быть, проблемы со DNS? Что скажет
ping name.of.ntp.server перед вызовом ntpdate?

-- 
Best regards,
 ASA                            mailto:llb@udm.ru

[Comm] Re: Сговор NTP-серверов

[Oleg N. Kayunov]

ASA wrote:

>Hello Oleg,
>
>Sunday, October 20, 2002, 4:53:59 AM, you wrote:
>
>ONK>      Заметил странную вещь.
>ONK> Для синхронизации использую ntpdate (свой ntp-сервер отключаю) при
>ONK> dial-up-е.
>ONK> В соотв. скрипте у меня прописано что-то около двух десятков
>ONK> ntp-серверов (начиная с Московских, ест-нно). Если не удаётся
>ONK> синхронизация с одним скрипт идёт к следующему и т.д.
>ONK>      В большинстве случаев синхронизация удаётся с первого же сервера. И
>ONK> ладно.
>
>ONK>      Странность в следующем - если синхронизация таки не удаётся с первым
>ONK> же сервером (какой-то из zenon-ов), то она, в подавляющем большинстве
>ONK> случаев, не удаётся и со всеми остальными.
>а эти сервера раньше проверялись на валидность (т.е. на то, что
>они действительно предоставляют сервис ntp)?
>
    По факту проверяются (хоть и не уверен, что все) - как я уже 
говорил, _иногда_ при отказе 1-го сервера срабатывает один из других по 
списку. Но редко. Можно, конечно проверить - какие случалось 
срабатывали, какие нет. Кроме того, до внесения в начало списка 
московских/российских серверов использовались некоторые из тех 
(забугорных), что сейчас стоят в конце списка.

>
>
>ONK>      Сабж, однако.
>ONK>      Но не всегда. Достаточно редко, но бывает, что обломившись на первом
>ONK> сервере, синхронизация таки проходит с одним из следующих в списке. Т.е.
>ONK> дело, похоже, не в особенностях того или иного сеанса dial-up-а, как
>ONK> такового.Да и повтор, в рамках того же dial-up сеанса, но через 
>ONK> некоторое время, иногда даёт успешный результат.
>
>Как я догадываюсь, ntp идет первым действием сразу после
>дозвона? 
>
    Нет, запускаю вручную (чтоб не досаждать при срывах связи).
Т.е. немного погодя.

>Может быть, проблемы со DNS? Что скажет
>ping name.of.ntp.server перед вызовом ntpdate?
>
    С ping-ом тоже непонятки (в другом письме) - иногда не 
досвистывается до машин, с котороми другие программы успешно 
устанавливают соединение (в том же сеансе диалап-а).


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

[Comm] ëÁË retrain ÐÒÉ×ÏÄÉÔ Ë "ÓÇÏ×ÏÒÕ" NTP, DNS É ÐÒÏÞÉÈ ÓÅÒ×ÅÒÏ×

[Henri Bourbon]

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

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

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

Олег,  у меня была догадка, в чем ваша проблема, и когда вы пожаловались
*еще  и на DNS*, то эта догадка стала больше похожей на правду. Все дело
в  отстойности модемного соединения и потере пакетов во время ретрейнов.
Если  при  отсылке  UDP-пакета  (а NTP, как и DNS, использует в качестве
протокола  транспортного уровня именно UDP) происходит ретрейн (наиболее
вероятная и неприятная вещь), либо пакет пропадет по каким угодно другим
причинам, то никто не будет жаловаться на пропажу пакета либо передавать
его   повторно.   ntpdate   просто   скажет   "no  server  suitable  for
synchronization found", а ping скажет "unknown host".

Ни  протокол NTP, ни конкретные NTP-серверы, ни какие-то другие проблемы
на серверной стороне тут ни при чем.

Полагаю,  при  наличии  минимальной изобретательности и желания вы легко
можете проверить (не)правильность моей версии происходящего.

-- 
HB

[Comm] Re: Как retrain приводит к "сговору" NTP, DNS и прочих серверов

[Oleg N. Kayunov]

Henri Bourbon wrote:

>On 20 Oct 2002  3:53, Oleg N. Kayunov wrote:
>
>>Заметил странную вещь. Для синхронизации использую ntpdate (свой
>>ntp-сервер отключаю) при dial-up-е. В соотв. скрипте у меня прописано
>>что-то около двух десятков ntp-серверов (начиная с Московских,
>>ест-нно). Если не удаётся синхронизация с одним скрипт идёт к
>>следующему и т.д. В большинстве случаев синхронизация удаётся с
>>первого же сервера. И ладно.
>>
>
>>Странность в следующем - если синхронизация таки не удаётся с первым
>>же сервером (какой-то из zenon-ов), то она, в подавляющем большинстве
>>случаев, не удаётся и со всеми остальными.
>>
>
>Олег,  у меня была догадка, в чем ваша проблема, и когда вы пожаловались
>*еще  и на DNS*, то эта догадка стала больше похожей на правду. Все дело
>в  отстойности модемного соединения и потере пакетов во время ретрейнов.
>Если  при  отсылке  UDP-пакета  (а NTP, как и DNS, использует в качестве
>протокола  транспортного уровня именно UDP) происходит ретрейн (наиболее
>вероятная и неприятная вещь), либо пакет пропадет по каким угодно другим
>причинам, то никто не будет жаловаться на пропажу пакета либо передавать
>его   повторно.   ntpdate   просто   скажет   "no  server  suitable  for
>synchronization found", а ping скажет "unknown host".
>
    Ваша гипотеза представляется мне вполне реалистичной и впервый 
момент показалось, что она описывает и мой случай. Но потом я понял, что 
вряд-ли это относится конкретно к моему случаю.
    Причина в том, что у меня постоянно (на всё время коннекта) включён 
звук модема. А ретрейн, ИМХО, на слух резко отличается от того 
стандартного шипения, которое характерно для коннекта на 
высокоскоростных протоколах.. И мне (ИМХО-же) доводилось слышать эту 
процедуру - когда кто-то подымал во время коннекта трубку на 
параллельном телефоне, так что я могу опознать на слух наличие сбоя в 
соединении.
    Так вот, во время описанных мною сбоев такого рода сбоев я не замечал.
    Похоже причина (в данном конкретном случае) в чём-то другом.

>
>
>Ни  протокол NTP, ни конкретные NTP-серверы, ни какие-то другие проблемы
>на серверной стороне тут ни при чем.
>
>Полагаю,  при  наличии  минимальной изобретательности и желания вы легко
>можете проверить (не)правильность моей версии происходящего.
>
    Ретропроверка, похоже, не подтверждает эту версию.
Но я буду обращать на это внимание далее.

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

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

[Henri Bourbon]

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

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

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

Если  я  правильно  понимаю,  нужно  взять  эти  самые  20 NTP-серверов,
пообщаться  с  ними  минимальное  время,  установить  время на локальном
компьютере  и завершить процесс. Вероятно, такое большое кол-во серверов
взято для максимальной надежности и точности установки времени. Практика
(не  столько  моя  личная, сколько людей, писавших NTP FAQ, а тж. самого
проф.  D.  Mills,  пишущего  ntpd  )  показывает,  что  увеличение числа
эталонных  серверов  больше  10  не  улучшает точность. Ну да ладно, это
мелочь.

Именно описанное в предыдущем абзаце и делает команда
ntpd -q

(в отличие от `ntpd` без параметров)

При   этом   работают   весьма   и   весьма   тонкие  алгоритмы  отброса
"подозрительных"  источников  времени,  отбора  наиболее близких к корню
синхронизации  (stratum  0) и достоверных источников, а затем нахождению
некоего  хитрого  средневзвешенного значения времени по всем достоверным
источникам. Алгоритмы, над которыми проф. Милз работал более 10 лет.

На   другой   же   чашке   весов   скрипт,  использующий  алгоритмы, над
которыми  Олег  Каюнов  работал  пару дней. Скрипт использует дуболомную
программу   ntpdate  (замечательная,   надо сказать, программа была году
этак в 1993-м).

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

# ntpd -q >& /dev/null &

-- 
HB

[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.

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

[ASA]

Hello Oleg,

Monday, October 21, 2002, 6:04:48 PM, you wrote:

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

-- 
Best regards,
 ASA                            mailto:llb@udm.ru

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

[aek]

Hello ASA,

Monday, October 21, 2002, 9:18:25 PM, you wrote:

A> в  том  то и дело, что ntpd тоже синхронизирует время. Но делает
A> это деликатно, чуть-чуть замедляя или ускоряя ход часов так, что
A> программы,  для  которых  монотонность текущего времени критична
A> (например,  биллинг  телефонных  звонков),  не  замечают  ничего
A> подозрительного.  А  ntpdate,  по  большому  счету,  -  дубинка.
A> Утилита  для  быстрого  подвода часов после какой-нибудь аварии.
A> как  тебе  понравится,  если  после  ntpdate окажется, что некто
A> проговорил по телефону "минус сорок пять" секунд?

Разговор, как я понял именно об ежедневном "быстром подводе часов"
только с точки зрения ЭКСТРЕМАЛЬНОГО уменьшения трафика. При этом
в жертву сознательно приводится точность хода (у меня например +-5 сек.)
Я применяю такую же схему с "дубиной" ntpdate.
Скажите мне, как заставить ntpd сверятся со списком эталонных
серверов один раз в сутки в четко выставленный час, "деликатно корректируя
свой ход"??? Я сразу похороню свои скрипты и воздам Вам хвалу.

-- 
Всех благ!
Анатолий

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

[ASA]

Hello aek,

Tuesday, October 22, 2002, 8:21:40 AM, you wrote:

a> Разговор, как я понял именно об ежедневном "быстром подводе часов"
a> только с точки зрения ЭКСТРЕМАЛЬНОГО уменьшения трафика. При этом
ntpd много трафика не ест никогда.

a> Скажите мне, как заставить ntpd сверятся со списком эталонных
a> серверов один раз в сутки в четко выставленный час, "деликатно корректируя
a> свой ход"??? Я сразу похороню свои скрипты и воздам Вам хвалу.
Я в подобной ситуации сделал по-другому. Запустил часы как есть,
ntpd   сам  по  себе,  без  внешней  синхронизации  (есть  такая
возможность,  см.  документацию).  Через  неделю  снял  разницу,
высчитал  поправку,  ввел  ее  в  конфиг ntpd, потом через месяц
опять  высчитал  поправку, в результате я получил характеристику
скорости часов в CMOS данной машины, а за год часы ушли не более
чем   на  1-2  секунды  (т.к.  в  течении  этого  года  пришлось
перезагружаться  несколько  раз).  И  это  -  в  условиях  сети,
умышленно отрезанной от интернета.

-- 
Best regards,
 ASA                            mailto:llb@udm.ru

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

[aek]

Hello ASA,

Tuesday, October 22, 2002, 12:07:57 PM, you wrote:

a>> Разговор, как я понял именно об ежедневном "быстром подводе часов"
a>> только с точки зрения ЭКСТРЕМАЛЬНОГО уменьшения трафика. При этом
A> ntpd много трафика не ест никогда.
Согласен, по этому и выделил словечко...

a>> Скажите мне, как заставить ntpd сверятся со списком эталонных
a>> серверов один раз в сутки в четко выставленный час, "деликатно корректируя
a>> свой ход"??? Я сразу похороню свои скрипты и воздам Вам хвалу.
A> Я в подобной ситуации сделал по-другому. Запустил часы как есть,
A> ntpd   сам  по  себе,  без  внешней  синхронизации  (есть  такая
A> возможность,  см.  документацию).  Через  неделю  снял  разницу,
A> высчитал  поправку,  ввел  ее  в  конфиг ntpd, потом через месяц

"как ввел поправку" - если можно конкретную строчку плз, применю.

A> опять  высчитал  поправку, в результате я получил характеристику
A> скорости часов в CMOS данной машины, а за год часы ушли не более
A> чем   на  1-2  секунды  (т.к.  в  течении  этого  года  пришлось
A> перезагружаться  несколько  раз).  И  это  -  в  условиях  сети,
A> умышленно отрезанной от интернета.


-- 
Всех благ!
Анатолий

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

[ASA]

Hello aek,

Tuesday, October 22, 2002, 12:22:11 PM, you wrote:

A>> возможность,  см.  документацию).  Через  неделю  снял  разницу,
A>> высчитал  поправку,  ввел  ее  в  конфиг ntpd, потом через месяц

a> "как ввел поправку" - если можно конкретную строчку плз, применю.
дока по ntpd
смотреть в той области, где описываются эталонные источники
времени. Прикол в том, что CMOS тожн можно забацать таким
источником. Арифметических подробностей не помню за давностью
лет.

-- 
Best regards,
 ASA                            mailto:llb@udm.ru

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

[Ruslan N. Balkin]

[-- Attachment #1: Type: text/plain, Size: 582 bytes --]

On Tue, 22 Oct 2002 10:21:40 +0700
aek wrote:

> Разговор, как я понял именно об ежедневном "быстром подводе часов"
> только с точки зрения ЭКСТРЕМАЛЬНОГО уменьшения трафика. При этом
> в жертву сознательно приводится точность хода (у меня например +-5 сек.)
> Я применяю такую же схему с "дубиной" ntpdate.
> Скажите мне, как заставить ntpd сверятся со списком эталонных
> серверов один раз в сутки в четко выставленный час, "деликатно
> корректируя свой ход"??? Я сразу похороню свои скрипты и воздам Вам
> хвалу.
# vi /etc/crontab

-- 
С уважением,
Балькин Руслан.

[-- Attachment #2: For security, this message has been digitally signed. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Henri Bourbon]

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