| 最終更新日: 2002/12/12 JST | このメモの位置付け: 記録 |
C-dex JST2000 を時刻源とした NTP サーバーを運用するためのメモを残します。
2002/12/12 JST 現在の FreeBSD 4-STABLE 付属の ntp のバージョンは 4.1.0 です。 このバージョンには 標準電波 JJYを時刻源とするドライバ(参照時計)がありません。 2002/07/13 JST 以降の ports でインストールを行ってください。 2002/11/04 UTC に FreeBSD 5-CURRENT に ntp 4.1.1b がインポートされました。 これ以降の 5-CURRENT(5.0-RELEASE 以降等) は ports をインストールする必要はなく標準の ntpd で問題ありません。 ntpd の ports は 2 つありますが(net/ntp とnet/ntp-devel), その特性について書くことはテーマではないので省略します。 歴史的事情(4.1.72 で検証した)により net/ntp-devel (4.1.72 ベース)について記述します (本質的には 4.1.0 の時代あるいはそれよりも前, 後とも変わりません)。
$ cd /usr/ports/net/ntp-devel $ make install
/etc/rc.conf に以下の記述を{加え|変更し}ます)
xntpd_enable="YES" xntpd_program="/usr/local/bin/ntpd" xntpd_flags="-N high -p /var/run/ntpd.pid"
/etc/ntp.confに以下の記述を{加え|変更し}ます)
server 127.127.40.0 prefer mode 2 # C-dex JST2000 fudge 127.127.40.0 time1 0.070
実際には私のところの環境では下記の通り記述しています
driftfile /etc/ntp.drift server 127.127.40.0 prefer mode 2 # C-dex JST2000 fudge 127.127.40.0 time1 0.070 server 127.127.1.1 # local clock fudge 127.127.1.1 stratum 6 server ntp1.jst.mfeed.ad.jp # MFEED NTP Server #1 server ntp2.jst.mfeed.ad.jp # MFEED NTP Server #2 server ntp3.jst.mfeed.ad.jp # MFEED NTP Server #3
前提条件として, 127.127.40.0 の 40 は JJY ドライバを表す番号を示すので, これしか選択はありませんが, 0 はシリアルポート(この場合 COM1)を表す数字になります。 が厳密には /dev/jjy0 を指していて, これは /dev/cuua0 を指すように, 事前にシンボリックリンクを張る必要があります(jjy0 の指す先が cuaa1 でもかまわない, お勧めではありませんが)。
# ln -s cuaa0 /dev/jjy0
-N high は高優先度(リアルタイム優先度)で動作することを指示するもので,
FreeBSD 上で動く ntpd は rtprio(2) システムコールを使用して非常に高い優先度で動作します。
これがあるのと無いのとでは, 高負荷時(make world 中等)の時刻精度の安定度に顕著に違いがでます。
JJY ドライバの選択(127.127.40.0)と, 正しく同期している中から優先的に選ぶ(prefer)のと, C-dex JST2000(mode 2)であることを意味します。 mode に関しては, 他には 1 が選択可能で トライステート社製 TS-JJY01 が使えます。特に指定が無い場合は mode 0 として即ち mode 1 と解釈されます。 まぁどちらにせよ, 明示的に指定した方がよいでしょう。3 以降は今のところありません。 0, 1, 2 以外を指定した場合, そもそも指定が無かったものとして扱われます。
運用してみて, また色々と調べてみた結果, どうやらびみょーに補正を入れた方がよくて, ドライバが得た時刻に対して 0.070 秒(70msec)追加すると良いようです。 根拠としては, 1 秒間に 960 バイト (9600bps/スタートビット 1/ストップビット 1/パリティ無し) 転送できる状態で, 送信 4 バイト, 受信 17 バイトなので, 約 22msec かかるところでもって, データの取得精度が 100msec (内部精度は±1msecのようですが)なので, ±50msecの生じる誤差が〜って話なのでしょうが, びみょーに違う気がします(それだけでないというか, なんで一律 +70msec でいいのかわからない)。
参照時刻源にMFEED の Stratum 2 サーバー を指定しています。 非常に精度が良いので時には(交差アルゴリズムによる選択の結果) JST2000 が偽時計(falseticker)と判定されてしまうこともあります。 まぁ電波状況による影響(停波等)でしょうが。あと, インターネットにつながらないとか, JST2000 の電源を止めてみたとか, 最悪の時でも PC 内蔵の RTC (Real Time Clock) で時刻供給ができるように設定しています (RTC の時は Stratum 7 サーバーになる)。
ntpq -pコマンドを実行します。
$ ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*JJY(0) .JJY. 0 l 17 64 377 0.000 -1.238 3.846
LOCAL(1) LOCAL(1) 6 l 3 64 377 0.000 0.000 0.004
-ntp1.jst.mfeed. nttpf-isdn0.crl 2 u 42 64 377 11.506 -22.806 0.401
+ntp2.jst.mfeed. nttpf-isdn1.crl 2 u 46 64 377 12.102 -22.750 10.831
+ntp3.jst.mfeed. nttpf-isdn1.crl 2 u 48 64 377 11.947 -23.187 7.416
十分観測した結果(reach が 377 の状態, これは 8 進数表現で pool [秒]毎に
1 ビットづつシフトされる), JJY(0) が * (peer 相手)で,
MFEED の Stratum2 サーバーが候補(+)ないしは, それよりも低い状態(-)にあることを示しています。
| キーワード | 意味 | 単位 |
|---|---|---|
| remote | 時刻参照相手のアドレス | |
| refid | 参照識別子 | |
| st | 参照元 Stratum | |
| t | 相手の通信種類(ローカル, ユニ/マルチ/ブロードキャスト) | |
| when | 時刻回収からの経過時間 | 秒 |
| poll | 時刻回収間隔 | 秒 |
| reach | 到達状態 | |
| delay | 時刻回収にかかった時間 | msec |
| offset | カーネル時刻との差 | msec |
| jitter | 回収にかかった時間の変動 | msec |
| 文責:重村 法克(nork@ninth-nine.com) | Norikatsu Shigemura(nork@ninth-nine.com) |