=?iso-8859-1?q?=5BComm=5D_=EB=C1=CB_retrain_=D0=D2=C9=D7=CF=C4=C9=D4_=CB_?= =?iso-8859-1?q?=22=D3=C7=CF=D7=CF=D2=D5=22_NTP=2C_DNS_=C9_=D0=D2=CF=DE=C9?= =?iso-8859-1?q?=C8_=D3=C5=D2=D7=C5=D2=CF=D7?=

[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