14 Jul 15 11:25, Victor Sudakov wrote to Vova Uralsky:
VU>> Взглянул незамутнённым взглядом... Тебя не смущает оффсет в полторы VU>> секунды? Тебя не смущает VS> Меня прежде всего смущает, что напротив одного из пиров нарисован VS> "*", что означает "the peer the server is currently synchronizing VS> to." По моему убеждению, если с пиром что-то не так (оффсет большой
С чего бы вдруг? У нс есть более или менее здоровая тройка, из которой выбрали одного, с кого в данный момент получаем время. Оффсет -- это не проблема, вот если у пира вдруг резко изменился оффсет, подскочили jitter, dispersion, то есть причины перестать этому пиру доверять. Если такое стряслось со всеми пирами, то стоит перестать доверть себе, что и происходит.
VS> или другая проблема), звездочки быть не должно. А если звездочка VS> есть, значит пир устраивает и наш стратум никак не должен быть 16.
Поскольку нам до этого пира как до луны, раздавать такое время нет смысла, так что 16 вполне соответствует.
VU>> что 129.73 отстоит от остальных на почти 0.2 VU>> секунды? Попробуй остановить ntpd, echo > /твой/ntp.drift, выставить VU>> время ntpdate и запустить ntpd снова. Или -x добавить. VS> Зачистка ntp.drift не помогает. В запуске ntpdate смысла не вижу, VS> т.к. ntpd_sync_on_start="YES" (что подразумевает -g).
Если оно срабатывает, откуда тогда такой безумный оффсет? Если три раза подрят сделать ntpdate к одному и тому же пиру, как будет при этом меняться оффсет? Я бы всё-таки посоветовал сделать то что я предлагал. Если оффсет останется таким же, тогда не в ntp дело.
VU>> <телепат>У тебя это не в виртуалке случаем творится? VS> Hет, обычная железная машина, хоть и не новая. VS> CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (3009.11-MHz 686-class CPU)
Hа разогнанном железе оно тоже бывает, как впрочем и на гнилом. У меня как-то Ultra-10 вдруг так побежала вперёд, что drift коррекции не хватало и xntpd пару раз в день ресетил время.
