これはXenServer 7.1 CU1ホストです。 NTPは違うLinux distro。/etc/ntp.conf
server 0.north-america.pool.ntp.org
server 1.north-america.pool.ntp.org
server 2.north-america.pool.ntp.org
server 3.north-america.pool.ntp.org
サービスを再起動したら、統計を確認してください。
[root@c0101 ~]# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*tock.usshc.com .GPS. 1 u 56 64 1 32.936 36.036 0.000
www.tripout.tec 128.233.154.245 2 u 56 64 1 82.397 46.653 0.000
+t2.time.bf1.yah 98.139.133.62 2 u 57 64 1 17.589 26.316 0.000
mirrors.switch. 206.108.0.134 2 u 55 64 1 63.777 57.423 0.000
これを見ると（*アスタリスクを表示）、ポーリング時間は62秒でソース不良のために最小化され、オフセットが高いことがわかりますtock.usshc.com（他の環境のサーバーで確認したため、ジッタが0の-0.81）のみ表示されます。すべてのケースで、少なくとも低い数字が表示されるので、奇妙に見えます。たとえば、0.1待ち時間は正常に見えます。
約10分後、「間違ったソース」のためにサーバー選択がなく（*記号なし）、オフセットとジッタが悪くなります。
[root@c0101 ~]# ntpq -c peers
remote refid st t when poll reach delay offset jitter
==============================================================================
tock.usshc.com .GPS. 1 u 52 64 205 32.952 6021.94 4422.72
www.tripout.tec 128.233.154.245 2 u 64 64 377 82.473 5880.01 3724.85
t2.time.bf1.yah 98.139.133.62 2 u 3 64 377 17.812 6647.80 3704.53
mirrors.switch. 206.108.0.134 2 u 1 64 377 63.746 6678.59 3723.43
これはntpログであり、理解するのが難しいです。
[root@c0101 ~]# cat /var/log/ntp.log
14 Sep 12:01:20 ntpd[3914]: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16
14 Sep 12:01:20 ntpd[3914]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123
14 Sep 12:01:20 ntpd[3914]: Listen and drop on 1 v6wildcard :: UDP 123
14 Sep 12:01:20 ntpd[3914]: Listen normally on 2 lo 127.0.0.1 UDP 123
14 Sep 12:01:20 ntpd[3914]: Listen normally on 3 xapi1 10.131.250.22 UDP 123
14 Sep 12:01:20 ntpd[3914]: Listening on routing socket on fd #20 for interface updates
14 Sep 12:01:20 ntpd[3914]: 0.0.0.0 c016 06 restart
14 Sep 12:01:20 ntpd[3914]: 0.0.0.0 c012 02 freq_set kernel 500.000 PPM
14 Sep 12:01:21 ntpd[3914]: 0.0.0.0 c61c 0c clock_step +1014.260362 s
14 Sep 12:18:15 ntpd[3914]: 0.0.0.0 c614 04 freq_mode
14 Sep 12:18:16 ntpd[3914]: 0.0.0.0 c618 08 no_sys_peer
14 Sep 12:19:39 ntpd[3914]: ntpd exiting on signal 15
14 Sep 12:19:39 ntpd[4689]: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16
14 Sep 12:19:39 ntpd[4689]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123
14 Sep 12:19:39 ntpd[4689]: Listen and drop on 1 v6wildcard :: UDP 123
14 Sep 12:19:39 ntpd[4689]: Listen normally on 2 lo 127.0.0.1 UDP 123
14 Sep 12:19:39 ntpd[4689]: Listen normally on 3 xapi1 10.131.250.22 UDP 123
14 Sep 12:19:39 ntpd[4689]: Listening on routing socket on fd #20 for interface updates
14 Sep 12:19:39 ntpd[4689]: 0.0.0.0 c016 06 restart
14 Sep 12:19:39 ntpd[4689]: 0.0.0.0 c012 02 freq_set kernel 500.000 PPM
14 Sep 12:19:40 ntpd[4689]: 0.0.0.0 c61c 0c clock_step +1.067923 s
14 Sep 12:19:41 ntpd[4689]: 0.0.0.0 c614 04 freq_mode
14 Sep 12:19:42 ntpd[4689]: 0.0.0.0 c618 08 no_sys_peer
14 Sep 12:22:58 ntpd[4689]: 0.0.0.0 c628 08 no_sys_peer
14 Sep 12:26:11 ntpd[4689]: 0.0.0.0 c638 08 no_sys_peer
ここにいる追加出力そしてntpq -c as私が理解しようとする他のものもあります。
問題を解決するために、次のリンクを使用してきました。 http://support.ntp.org/bin/view/Support/TroubleshootingNTP https://rags.wordpress.com/2011/10/17/how-to-debug-ntp-issues/
答え1
仮想マシンの場合は、以下を確認してください。
ntp.confに設定しました
tinker panic 0（メモ:これはconfファイルの最初の行でなければなりません！ ）。これにより、時計があまりにもドリフトしている場合にntpdが機能しないようにすることができます。そして…変換モード（ntpd -x）で実行されていないことを確認してください。変換モードは、段階的クロッキングではなく段階的に調整を試みます。クロックがスルーレートより速くドリフトする場合、これは仮想マシンで問題になる可能性があります。
答え2
クロックソースをdom0（管理仮想マシン）ではなくxen（ハイパーバイザー）に変更すると、この問題を解決できます。/opt/xensource/libexec/xen-cmdline --set-dom0 clocksource=xen
別のより複雑な修正は、ティックの頻度を調整することです。このリンク
現在のバージョンの一部のバグと特定の種類のDellハードウェアを使用しているため、時計が速くドリフトしているため、NTPが時計を調整できない理由に関する情報はあまりありません。
新しいバージョンで修正がリリースされた場合です。