[VladDV]

в сеть не смотрят »

Что это значит? Они не подключены вообще ни к какой сети или у них нет доступа в интернет? Если второе, тогда вам нужен в сети сервер времени (NTP-сервер), с которым можно будет синхронизироваться. Можно поднять его допустим на дебиане (пример, еще). Для него откройте доступ в интернет по протоколу ntp (123/UDP).

[vadblm]

Что это значит? »

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

Делаем так:

выбираем хост, у которого RTC поточнее, он будет сервером, там поднимаем ntpd с таким примерным конфигом:

Код:

driftfile /path/to/ntp.drift
server 127.127.1.0 maxpoll 2

driftfile — пустой файл где удобно, который может писать/читать ntpd. То есть делаем что-то типа touch /var/run/ntp.drift; chmod 600 /var/run/ntp.drift; chown ntp:ntp /var/run/ntp.drift

Второй будет клиентом, у него аналогично подымаем ntpd c таким примерным конфигом:

Код:

driftfile /path/to/ntp.drift
server <IP адрес "сервера" из предыдущего параграфа> iburst

Ставим на обоих машинах часики максимально точно руками.

Запускаем на обоих машинах ntpd.

Проверяем синхронизацию ntpq -p

Разумеется, в фаерволах должен быть разрешён доступ друг к дружке по 123/UDP.

[VladDV]

vadblm, а что даст использование driftfile на сервере времени? Насколько я понимаю, он может рассчитывать смещение времени на системных часах относительно сервера точного времени. В данном случае сервера точного времени не будет, а значит и дрифт рассчитать неоткуда..

[vadblm]

Насколько я понимаю, он может рассчитывать смещение времени на системных часах относительно сервера точного времени »

Пишут, что driftfile помогает некоторое время, если сервера не доступны, эмпирически продолжать рассчитывать "точное" время.

В данном случае сервера точного времени не будет, а значит и дрифт рассчитать неоткуда.. »

Сервера не может не быть, так устроен ntpd, в данном случае в его роли выступает system clock —так пишут в документации ntpd, но ведь его же и призван устанавливать ntpd... видимо, имеется в виду RTC (hwclock), который далеко не идеален:

Код:

$ hwclock 
Вс. 30 сент. 2012 15:56:21  -0.484700 секунд

Во всяком случае, от driftfile хуже не будет.

[VladDV]

Пишут, что driftfile помогает некоторое время, если сервера не доступны, эмпирически продолжать рассчитывать "точное" время. »

Все верно, но для этого файл сначала должен быть рассчитан. А для этого нужно хотя бы на 1-2 суток дать нашему ntp-серверу синхронизироваться с точным сервером времени. Иначе файл будет рассчитан некорректно, и в лучшем случае от него не будет пользы, а в худшем - будет даже вред. Тут все зависит от реализации ntpd, скорее всего он просто не будет определять дрифта и сервер будет строго следовать аппаратным часам.

P.S.: постараюсь выкроить время и проверить сие утверждение на практике.

[VladDV]

Вот кстати выдержка из п. 7.2 RFC 5905:

Others, like the frequency tolerance (also called PHI), involve an assumption about the worst-case behavior of a system clock once synchronized and then allowed to drift when its sources have become unreachable.

[vadblm]

Вот подумалось, может будет лучше сделать две машинки равноправными пирами? Примерно так
Первая:

Код:

server 127.127.1.0
peer <IP второй>

Вторая:

Код:

server 127.127.1.0
peer <IP первой>

Тут от driftа будет польза.

[VladDV]

Хм.. А что это даст? Идея в том, чтобы получить среднее отклонение для этих двух машин? Если конечно на одной машине часы отстают, а на другой спешат, тогда она сработает

Вообще интересно бы услышать топикстартера в чем именно у него задача - время должно быть синхронизировано только между этими двумя серверами и неважно, насколько время будет отличаться от "внешнего" времени, или же все таки время должно соответствовать глобальному? В первом случае вышеописанных методов вполне хватит, а во-втором, мне кажется не должно возникнуть больших проблем с открытием порта 123 в инет для любого из этих серверов, либо поднятием доп сервера времени в сети.

[vadblm]

Идея в том, чтобы получить среднее отклонение для этих двух машин? Если конечно на одной машине часы отстают, а на другой спешат, тогда она сработает »

Она сработает в любом случае, независимо от того, в какую сторону убегают часы на обоих машинах.

Вообще интересно бы услышать топикстартера в чем именно у него задача - время должно быть синхронизировано только между этими двумя серверами и неважно, насколько время будет отличаться от "внешнего" времени, или же все таки время должно соответствовать глобальному? В первом случае вышеописанных методов вполне хватит, а во-втором, мне кажется не должно возникнуть больших проблем с открытием порта 123 в инет для любого из этих серверов, либо поднятием доп сервера времени в сети. »

Ещё можно приобрести недорогой USB NMEA GPS приёмник (цена вопроса ~$50) и довольно точное время получать с него

Код:

server 127.127.20.0