ノート:Network Time Protocol
核拡散防止条約もNTPだと思うのですが。
- NPTです。--Episteme 2006年5月17日 (水) 16:05 (UTC)
OSごとの操作説明は必要？
編集OSごとの操作説明は必要なのでしょうか。手順として「コマンドプロンプトを～"cmd"と入力。」とまで書くのは NTP の項目として細かすぎではないでしょうか。 By 健ちゃん 2006年11月4日 (土) 04:51 (UTC)
ひとまずcmdからの一連操作をコメントアウトし、XPのNTP操作に記載変更してみました。--Ciolo 2006年11月9日 (木) 17:43 (UTC)
例えば「Windows XP や MacOS X では標準で NTP クライアント機能を持っている」くらいの記述でもいいと思うのですがどうでしょうか。また、なぜ正確に時刻を合わせることが重要か等 ntp の成立背景などの説明等あればと思います。あと SNTP との関連とか。 By 健ちゃん 2006年11月12日 (日) 15:17 (UTC)
統合提案
編集Network Time ProtocolとSimple Network Time Protocolの統合を提案します。理由としては次のものを挙げます。
- NTPとSNTPは仕組みとしてほぼ重複する
- SNTP 単独に書ける内容が少ない
- 他言語版でもNTPとSNTPは一緒になっている
現状SNTPは修正依頼の名のもとにサブスタブ以下の状態となっていますが、過去版には有用な内容が眠っています。これらをNTPに統合することで記述の充実が図れると思います（逆に「各ソフトウェアにおける設定法」あたりはバッサリ切ってしまうのもアリだと思います）。ご意見お待ちしております。--端くれの錬金術師 2007年9月23日 (日) 02:02 (UTC)
- 賛成です。過去版を復活して統合すればよいと思います。Ribbon 2007年10月20日 (土) 03:37 (UTC)
- 同じく賛成。たしかに設定法あたりはバッサリでいいと思います。--Monaneko 2007年10月20日 (土) 06:12 (UTC)
このＮＴＰの記述について
編集検討事項
編集・統合案について
タイムサービスプロトコルとしてNetwork Time ProtocolとSimple Network Time Protocolを統合して書くには問題ないと思います。
・問題点
ＲＦＣ１３０５をある程度読んで、ＮＴＰソースコード見たことがおありでしょうか？
ここで記述されている内容がＳＮＴＰの範囲しか記述してないことが問題であり、ＳＮＴＰにはないＮＴＰの部分の記述がほとんどありません。
しいて言えば複数時計を選択する仕様が明記されている部分がＳＮＴＰの仕様として謳われていない部分です。
このドキュメントはＳＮＴＰとして乗せるドキュメントだと思います。
ＵＮＩＸ系ＯＳのＮＴＰ利用者が日本語版ＲＦＣ２０３０を見て書いた内容に見えます。
・記述がおかしいと思われる点
－閏秒の扱い
閏秒はマスター時計より閏秒情報を取得した場合、閏秒識別子（Leap Indicator）に挿入/削除フラグを立てると言うだけです。
閏秒識別子で時間挿入/削除の処理は行いません。
なぜなら、ＳＮＴＰとＮＴＰは親時計の差分を元に自分の時計を補正する仕組みだからです。
さらに、ＮＴＰの場合、上位時計のクロック揺らぎを計測する処理があるので揺らぎが大きいと、親時計を信用できる時計の候補からはずす処理を行います。
ＮＴＰのソース見てもらえばおかしいことはわかると思います。
ＲＦＣ１３０５にもそんな記述はありません。
－stratum 16
stratum値は、０～１５までです。それ以外の値はＲＦＣではリザーブとなっています。
そのため実際のＮＴＰ処理では、stratum ０として送出します。
通信上のstratum値＝０はクライアントは不正値扱いであるため、ＳＮＴＰやＮＴＰでも時計を同期しない仕組みに成ってます。
stratum値＝０を有効とする処理は、時計ソースと直結していいるＮＴＰ内部処理上だけです。
ただし、ＮＴＰサーバで２次装置へ伝送する場合にstratum値をインクリメントするため、stratum値＝１がパケット上送出されます。
－ドリフトを調整して時刻を目的の時刻に徐々に近づけていく実装が正しい。
ＮＴＰの範疇にない仕様です。
ＲＦＣ１３０５のオプション記述では、時計反映処理においていくつか案を上げています。
結局のところシステムに合わせて実装者が検討し仕様決定しなさいとなっています。
－桜時計
ＳＮＴＰクライアントです。ＮＴＰの処理は一切してません。
・疑問点
ＷｉｎｄｏｗｓＸＰのＮＴＰ
マイクロソフトはＮＴＰと名乗っているが、シメントリック（symmetric）モードでパケット交換する仕組みにしただけです。
これで本当にＮＴＰと言えるのでしょうか？
ユーザーからは、ＮＴＰにおける上位時計信頼性試験結果も見えないし、複数時計制御も不明、ポーリングタイマー制御も不明な状態です。
本来のＮＴＰといわれるものの実装からは機能的に大幅削除されれており、シメントリックモードで動作するＳＮＴＰにしか見えません。
ＮＴＰの一部が実装されればＮＴＰと名乗るならＳＮＴＰもＮＴＰになってしまいますね？
これについて詳しい方はおられますか？
・各ソフトウェアにおける設定法
ＮＴＰはプロトコルであり不要な気がします。
2036年問題の誤記について
編集NTP time がロールオーバーするのは 2036年2月7日(UTC,JST共に)ではないでしょうか？ なぜか日本語のWebページには2036年2月6日という誤った記述が多いですね。
2036年問題に触れるなら RFC 4330( SNTP v4) についても、記述すべきでしょう。 リファレンス実装のntpや chrony(これはNTPを実装しているわけではない)では、 問題なく2036年を越えることができます(実際に試してみれば分かります)。 --126.113.96.194 2009年8月23日 (日) 09:39 (UTC)
- RFC 4330の記述を確認し、日附の修正と、RFC 4330に記載されている問題回避策について記載しました。「日本語のWebページには2036年2月6日という誤った記述が多い」ことについては[1]に記載があります。(jawpにまで書かれているということも大きかったのでしょうが) nnh（会話） 2013年5月24日 (金) 03:03 (UTC)
時間分解の精度限界の問題について
編集NTP/SNTPの標準フォーマット上ではやりとりする時間データはおよそナノ秒までの精度となっていますが、128ビットのオプショナルエリアを使用すればもっと精度が上げられますね。 しかしたかが128ビットでしかないのが実情で、32ビット×4をどのように分割して利用するのか？について独自仕様ではないか？と思われます。 このあたりのフォーマット情報はありませんか？もちろんメーカー独自レベルでの保証データエリアでしょうから、エリアの拡張などの対応をしないことには根本的な解決ではないと思われます。独自のプロトコル利用でしょうか？その際の最大ビット数の情報もありましたら追記願います。
- 本文に要出典を張り付けましたが、NTPでの時刻精度が十分ではないと具体的に指摘している出典が存在しないのであれば、この節そのものを除去すべきではないでしょうか。--113.38.82.142 2013年2月3日 (日) 04:13 (UTC)
- 時刻精度について「送受信速度指標を上げることに対し弊害となっている」ことを示す出典が示されませんでしたので当該節を丸ごと除去しました。--113.38.82.142 2013年5月3日 (金) 14:02 (UTC)