ノート:Time Protocol

message: 本稿内で、他の時間系プロトコルに関する紹介が記載されていますが、このうち Network Time Protocol はかなり充実した記事になっているようです。また、Simple Network Time Protocolについても独立記事が存在し、かつてはかなり有用な内容を含んでいました (参照: 2006年11月4日 (土) 14:27版 が、現在はほとんど削り取られてしまっているようです。
そこで、独立した記事のあるものは「関連項目」節を設けてリンクを貼り、主要な仕組みの記述はそちらに譲って、本稿内では「比較」の記述にとどめることを提案します。また、SNTPの部分については一部転記、その他のプロトコルについても分割が考え得るところだと思いますが、いかがでしょうか。 --Kuropen（会話） 2013年2月10日 (日) 16:27 (UTC)
thread_title:  「他タイムプロトコルとの関係および紹介」について 

message: Network Time Protocol と、Simple Network Time Protocolの現状は知っていました。
「主要な仕組みの記述はそちらに譲って、本稿内では「比較」の記述にとどめる」について
確かにその方が全体的に纏まると思います。
　ですが、Network Time Protocolは間違い多く、ＳＮＴＰと共通部分しか記述されておらず、ＮＴＰオリジナルの記述が抜けております。
　残念ですが、プロトコルや実装に関する知識がないＮＴＰ利用者が、見える範囲で記述したと思われます。
　当方としては、ＮＴＰやＳＮＴＰが正しい記述をしてから、訂正させていただきたいです。
　ＮＴＰがこのままだと辞書としてはづかしくないですか？
　ざっと目をとうしただけでも下記は正しくありません。
===（１）概要===
　間違いの要因：ハードウェア時計（ＲＴＣ）とＯＳ時計の関係を知らないためだと思います。
　ＮＴＰの同期は、ＲＴＣの同期ではなく、ＯＳ時計の同期が目的です。
※根拠
　マルチタスクＯＳでは、ＲＴＣはＯＳ起動時にしかＯＳ時計に反映しません。
　その後は、コンピュータのクロックを分周した、タイマー割込みを積算してＯＳ時計を維持します。
　現在のコンピュータでも、タイマー割込みは、厳密な１秒は作れません。そのため時計がズレてゆくのです。　
　これは、ＲＴＣのズレより大きいのです。
　そのため、ネットワーク時計同期の仕組みが考えられました。
　ＲＴＣへの反映は、ＮＴＰの範疇外です。
　理由は、ＲＴＣはハードウェアであり、ＯＳにより反映方法が異なります。
　されらに、ＮＴＰ発祥のＵＮＩＸもそうですが、ユーザモードではＲＴＣ操作できません。
　これは、カーネルレベルで動作するドライバクラスしかできないのです。だから規格化していないのです。
※これは、ＯＳ実装の携われば知る事実です。
　ＲＴＣメインで使うＯＳは、シングルタスクのＯＳです。
　ＯＳが時計を必要とするのは、ファイルの書込みだけだからです。
===（２）処理の概略===
　これも正確ではありません。
　－「NTPサーバに接続」
　　正しくは、「接続はしません、UDPによるNTPパケット送信する」です。
　－「受け取った時刻情報を補正して自動的にミリ秒単位の精度で自機・OSの時計を校正する。」
　　正しくは、サーバから受取った時刻情報から、「サーバとの時刻差分を算出」し、実機のＯＳ時計の校正を行うです。
　　「通信遅延時間の計測」と書いている意味を正しく理解していれば、「閏秒の扱い」が嘘である事がわかるはづです。
　　精度に関しては、ＯＳ側ライブラリコールに依存します。
　　これがＲＴＣならば、秒単位です。市販されているＬＳＩを見ればミリ秒はまず売っていません。
===（３）ドリフトの修正===
　これは実装者が考える部分で記述はありません。
　少なくても、「RFC1305 NTP Version 3」か「RFC5905 NTP Version 4」と読んで、かつ実装経験があれば、間違いがわかるはづです。
===（４）NTPの実装===
　ntpdateは、ＳＮＴＰのユーティリティでクロックデーモンの登録して簡易的に時計合わせを提供したものです。
　つまりＮＴＰではありません。
===ＳＮＴＰ===
Simple Network Time Protocolの 2006年11月4日 (土) 14:27版の内容を拝見させていただきました。
ＮＴＰパケットに関する知識と、実装処理は正しい認識だと思いますが、消されていますね。残念！
thread_title: Kuropen様への回答

message: 間違いの要因：ハードウェア時計（ＲＴＣ）とＯＳ時計の関係を知らないためだと思います。
　ＮＴＰの同期は、ＲＴＣの同期ではなく、ＯＳ時計の同期が目的です。
※根拠
　マルチタスクＯＳでは、ＲＴＣはＯＳ起動時にしかＯＳ時計に反映しません。
　その後は、コンピュータのクロックを分周した、タイマー割込みを積算してＯＳ時計を維持します。
　現在のコンピュータでも、タイマー割込みは、厳密な１秒は作れません。そのため時計がズレてゆくのです。　
　これは、ＲＴＣのズレより大きいのです。
　そのため、ネットワーク時計同期の仕組みが考えられました。
　ＲＴＣへの反映は、ＮＴＰの範疇外です。
　理由は、ＲＴＣはハードウェアであり、ＯＳにより反映方法が異なります。
　されらに、ＮＴＰ発祥のＵＮＩＸもそうですが、ユーザモードではＲＴＣ操作できません。
　これは、カーネルレベルで動作するドライバクラスしかできないのです。だから規格化していないのです。
※これは、ＯＳ実装の携われば知る事実です。
　ＲＴＣメインで使うＯＳは、シングルタスクのＯＳです。
　ＯＳが時計を必要とするのは、ファイルの書込みだけだからです。
thread_title: （１）概要

message: これも正確ではありません。
　－「NTPサーバに接続」
　　正しくは、「接続はしません、UDPによるNTPパケット送信する」です。
　－「受け取った時刻情報を補正して自動的にミリ秒単位の精度で自機・OSの時計を校正する。」
　　正しくは、サーバから受取った時刻情報から、「サーバとの時刻差分を算出」し、実機のＯＳ時計の校正を行うです。
　　「通信遅延時間の計測」と書いている意味を正しく理解していれば、「閏秒の扱い」が嘘である事がわかるはづです。
　　精度に関しては、ＯＳ側ライブラリコールに依存します。
　　これがＲＴＣならば、秒単位です。市販されているＬＳＩを見ればミリ秒はまず売っていません。
thread_title: （２）処理の概略

message: これは実装者が考える部分で記述はありません。
　少なくても、「RFC1305 NTP Version 3」か「RFC5905 NTP Version 4」と読んで、かつ実装経験があれば、間違いがわかるはづです。
thread_title: （３）ドリフトの修正

message: ntpdateは、ＳＮＴＰのユーティリティでクロックデーモンの登録して簡易的に時計合わせを提供したものです。
　つまりＮＴＰではありません。
thread_title: （４）NTPの実装

message: Simple Network Time Protocolの 2006年11月4日 (土) 14:27版の内容を拝見させていただきました。
ＮＴＰパケットに関する知識と、実装処理は正しい認識だと思いますが、消されていますね。残念！
thread_title: ＳＮＴＰ

message: 「他タイムプロトコルとの関係および紹介」節がTime Protocolにある意味がよくわかりません。Time Protocolは、現在では実質的に使われていないプロトコルです。そもそも、特定のプロトコルの項目内にこのような記述があるのがおかしいので、やるのであれば「時刻同期プロトコルの比較」のような独立項目にするべきでしょう。--nnh（会話） 2019年3月7日 (木) 01:04 (UTC)
replies: text: 1年以上前の話ですが続けます。クロック同期（時刻同期）という項目を作成しましたので、こちらにまとめようと思います。もっとも、当該の節は出典皆無なのでどれくらい使えるのかという話もありますが……。--nnh（会話） 2020年6月24日 (水) 06:02 (UTC)

text: 一応、正式に分割提案を出しました。が、どれくらい統合できるものか。RFCの記載くらいしか統合できないのではないかという気もします。DAYTIMEプロトコルは場違い（応答として人間可読の時間を返すだけで、時間取得自体が目的ではない）なので、転記せず、単純に除去する予定です。--nnh（会話） 2020年6月29日 (月) 02:21 (UTC)
replies: text: :特にご意見がありませんでしたので、分割・統合を実施します。--nnh（会話） 2020年7月6日 (月) 09:20 (UTC)
thread_title:  「他タイムプロトコルとの関係および紹介」の扱いについて