コンテンツにスキップ

英文维基 | 中文维基 | 日文维基 | 草榴社区

ノート: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 ProtocolSimple Network Time Protocolの統合を提案します。理由としては次のものを挙げます。

  1. NTPとSNTPは仕組みとしてほぼ重複する
  2. SNTP 単独に書ける内容が少ない
  3. 他言語版でもNTPとSNTPは一緒になっている

現状SNTPは修正依頼の名のもとにサブスタブ以下の状態となっていますが、過去版には有用な内容が眠っています。これらをNTPに統合することで記述の充実が図れると思います(逆に「各ソフトウェアにおける設定法」あたりはバッサリ切ってしまうのもアリだと思います)。ご意見お待ちしております。--端くれの錬金術師 2007年9月23日 (日) 02:02 (UTC)[返信]

賛成です。過去版を復活して統合すればよいと思います。Ribbon 2007年10月20日 (土) 03:37 (UTC)[返信]
同じく賛成。たしかに設定法あたりはバッサリでいいと思います。--Monaneko 2007年10月20日 (土) 06:12 (UTC)[返信]

このNTPの記述について

[編集]

検討事項

[編集]

・統合案について
タイムサービスプロトコルとしてNetwork Time ProtocolSimple Network Time Protocolを統合して書くには問題ないと思います。

・問題点
 RFC1305をある程度読んで、NTPソースコード見たことがおありでしょうか?
 ここで記述されている内容がSNTPの範囲しか記述してないことが問題であり、SNTPにはないNTPの部分の記述がほとんどありません。
 しいて言えば複数時計を選択する仕様が明記されている部分がSNTPの仕様として謳われていない部分です。
 このドキュメントはSNTPとして乗せるドキュメントだと思います。
 UNIX系OSのNTP利用者が日本語版RFC2030を見て書いた内容に見えます。

・記述がおかしいと思われる点
 -閏秒の扱い
  閏秒はマスター時計より閏秒情報を取得した場合、閏秒識別子(Leap Indicator)に挿入/削除フラグを立てると言うだけです。
  閏秒識別子で時間挿入/削除の処理は行いません。
  なぜなら、SNTPとNTPは親時計の差分を元に自分の時計を補正する仕組みだからです。
  さらに、NTPの場合、上位時計のクロック揺らぎを計測する処理があるので揺らぎが大きいと、親時計を信用できる時計の候補からはずす処理を行います。
  NTPのソース見てもらえばおかしいことはわかると思います。
  RFC1305にもそんな記述はありません。
 -stratum 16
  stratum値は、0~15までです。それ以外の値はRFCではリザーブとなっています。
  そのため実際のNTP処理では、stratum 0として送出します。
  通信上のstratum値=0はクライアントは不正値扱いであるため、SNTPやNTPでも時計を同期しない仕組みに成ってます。
  stratum値=0を有効とする処理は、時計ソースと直結していいるNTP内部処理上だけです。
  ただし、NTPサーバで2次装置へ伝送する場合にstratum値をインクリメントするため、stratum値=1がパケット上送出されます。
 -ドリフトを調整して時刻を目的の時刻に徐々に近づけていく実装が正しい。
  NTPの範疇にない仕様です。
  RFC1305のオプション記述では、時計反映処理においていくつか案を上げています。
  結局のところシステムに合わせて実装者が検討し仕様決定しなさいとなっています。
 -桜時計
  SNTPクライアントです。NTPの処理は一切してません。

・疑問点
 WindowsXPのNTP
 マイクロソフトはNTPと名乗っているが、シメントリック(symmetric)モードでパケット交換する仕組みにしただけです。
 これで本当にNTPと言えるのでしょうか?
 ユーザーからは、NTPにおける上位時計信頼性試験結果も見えないし、複数時計制御も不明、ポーリングタイマー制御も不明な状態です。
 本来のNTPといわれるものの実装からは機能的に大幅削除されれており、シメントリックモードで動作するSNTPにしか見えません。
 NTPの一部が実装されればNTPと名乗るならSNTPもNTPになってしまいますね?
 これについて詳しい方はおられますか?

・各ソフトウェアにおける設定法
 NTPはプロトコルであり不要な気がします。

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)[返信]