На ntp.org пишут, что :
What happens if the Reference Time changes?Ideally the reference time is the same everywhere in the world. Once synchronized, there should not be any unexpected changes between the clock of the operating system and the reference clock. Therefore, NTP has no special methods to handle the situation.
Instead, ntpd's reaction will depend on the offset between the local clock and the reference time. For a tiny offset ntpd will adjust the local clock as usual; for small and larger offsets, ntpd will reject the reference time for a while. In the latter case the operation system's clock will continue with the last corrections effective while the new reference time is being rejected. After some time, small offsets (significantly less than a second) will be slewed (adjusted slowly), while larger offsets will cause the clock to be stepped (set anew). Huge offsets are rejected, and ntpd will terminate itself, believing something very strange must have happened.
Naturally, the algorithm is also applied when ntpd is started for the first time or after reboot.
Вопросы следующие:
tiny offset = конкретно сколько?
small offset = конкретно сколько?
huge offset = конкретно сколько?Как эти параметры можно задать?
Спасибо.
У меня возникали проблемы изза того, что локальные часы сильно отставали или убегали и ntp отказывался синхронизироваться.
Для этого добавлял в крон ntpdate -bu $server_ip
Можно написать скрипт, чтобы проверял разницу, и выполнял вышеописанную команду по наступления порогового значения
> Вопросы следующие:
> tiny offset = конкретно сколько?
> small offset = конкретно сколько?
> huge offset = конкретно сколько?
> Как эти параметры можно задать?
> Спасибо.1) никак. читайте RFC и man ntpd на предмет опций для подведения системных часов не плавно, а скачками.
2) используюте ntpdate для синхронизации при загрузке системы прежде, чем стартовать ntpd.
это стандартная проблема при севшей батарейке на материнке - "железные" часы сваливаются при длительном отсутствии внешнего питания.