NTP, SNTP負荷分散作戦所
NTP サーバは、(ネットワーク的に)近くて、(ping応答が)早いサーバを選択するのが鉄則。
まずはプロバイダが NTP サーバを提供してるか確認しましょう。
おいそこの clock.nc.fukuoka-u.ac.jp (133.100.9.2)使ってる奴!とりあえず変更しよう。な。
関連wiki
http://wiki.nothing.sh/page/NTP そういや、ARP tableをstaticに書くって
結構効果ありますな。ISPが提供する3台のstratum 2
(事実上 stratum1 相当とのこと)に対して
かならず±5ms程度のoffsetのブレが生じていたけど、
default gatewayへのstatic ARP entryを書いたらjitterが
1/5 になって常に1ms未満のoffsetになりますた。
もう自己満足の領域ですが。 地球の裏側にあるNTPサーバを参照しているんとはこれはまた
ずいぶん難儀なことで.
>>293
腐っているネットワークを自慢されてモナー
offsetの意味を穿き違えている悪寒も. RINGのはまさにntpdateで起動時に一発会わせるような使い方だけを
考えてるんだと理解してるんだが違うのか?
Ring側は一応 /etc/ntp.conf に書くやりかたも示してるよ。
http://www.ring.gr.jp/ring/ntp.html.ja
こういう使い方でも、実用上問題ない精度が得られるかと。
遠くのサーバに当たっても、1秒未満で合うでしょ。
それ以上の精度が確実に必要ならGPS受信機なりを買うべきかと。
インターネット経由の時刻同期に過大な期待をしないほうがいいかと。
(それはmfeedもringも変わらんよね) んま、中村正三郎がNTPについてなんも知らなかったのは確実だ罠。 >>297
あいつ何にもわかってないよな.
Ringで示している書き方をするとラウンドロビンのDNSが,偶然同じものを指す
可能性がある.NTPは3つの参照先があると正しい時間を選択する仕組みだが
その意味がなくなる.やっかいなことに偶然にしか起こりえない.
/.Jにも書いてあったけど,ring.nict.go.jpとかring.atr.jpといった中から
具合に自分に近いところを選び,ISPやmfeedと一緒にませて参照サーバ
として使うのが安全だろう.少なくともRingのサイトに書いてあることを
鵜呑みにしないほうがいい.
本当に「よくわからないけどやってみました」ってレベルだな(藁 そういや、こいつら実体は普通のanonymous FTPサーバだよね。
上り下りのトラフィック量に大きな差があると
パケットの行き帰りの遅延時間に差が生じて
誤差の原因にならんのかな。
何秒もずれるということはないだろうが いろいろ観察した結果,ntpの参照先としてring.nict.go.jpとring.atr.jpが
使い物になりそうだ(GJ!).特にring.nict.go.jpはやっぱりよくわかっている
なぁ,という感じがする.あとはちょっとお勧めできない.ring.aist.go.jpとか
core.ring.gr.jpとかダメダメだし.ring.housei.ac.jpとring.qgpop.netも
漏れなら参照しない. エロイ人、匿名希望 ◆rXpNDG7vbEさんのソフトを再ウプ希望 今見たらntp.ring.gr.jpが6台になってた
>ring.nict.go.jpとring.atr.jp
両方とも学術ネットワーク上のサーバだな。商用ISPからの接続だと
最寄のサーバを選ぶという観点からはあまりよろしくないな。 >>302
うちからだと
nictはjpix->sinet経由、atrは大手町WIDE経由で、遠くないよ。
昔とは違う。 ところで NTP version4 の Internet draft 化はどうなってるの?
mfeed のところにはv6も使えるようになったと書いてあって、アドレスが書いてあるだけ。
仕様は?と聞かれても言えない状態だよなぁ。ああいう風にしか書けないよな。 >>292
># NTPは行きと帰りの遅延時間が同一であるという仮定を
># しているので、2つの間に大きな差がある場合は大きな
># 誤差が出る。それでも、最悪RTT以上の誤差は生じないため、
国内の場合
ocn 系列のISP - verio 経由はダメで ocn内はOK
他のISP(接続先が国内)でも国外に出るような経路だとダメっぽ
最低限国内のpop数が少ないntp鯖を選ぶべき
うちの場合 ntp01.sinet.ad.jpになるわけだ インターネットマルチフィード「時刻情報提供サービス for Public」の提供開始について
http://www.mfeed.ad.jp/corporate/press/20050330.html
インターネットマルチフィード株式会社(略称:MFEED、本社:東京都千代田区、代表取締役社長:鈴木幸一)は、
これまで、インターネット上で日本標準時を正確に提供する共同実験を行ってまいりましたが、このたび独立
行政法人情報通信研究機構(NICT)の提供する「ネットワークによる時刻情報提供サービス(NTPサービス)」
を利用した本格サービス
『インターネットマルチフィード「時刻情報提供サービス for Public」』
として、2005年 3月 31日より提供開始します。
MFEEDでは、今後もインターネットの飛躍的かつ健全な発展を推進し、社会的インフラとしての信頼性向上に
寄与するサービスの提供に先駆的に取り組んでいきます。 >>301
tobeten.dyndns.org/~master/up/img/192.zip NTP応答速度ランキング
tobeten.dyndns.org/~master/up/img/194.zip NTP階層分析 >>310
これ、WiKiの中の人が保存してくれたらなぁ・・・とか言ってみるテスト つーかgeoなりsf.jpなりでアカウントとりゃいいじゃん。 >>311
Wikiにページ起こして出典を示して張っておけば? 匿名希望 ◆rXpNDG7vbE タソの計測ソフト再アップしていただけませんか?
ミラーとして残しておきたいのですが。いいでしょうか?>匿名希望 ◆rXpNDG7vbE タン と思ったら>>310のが生きてたので、消えないようにミラーしときますね。 sntp.mydns.toという実験中のNTPサーバを見つけました $ host sntp.mydns.to
sntp.mydns.to has address 221.252.29.22
$ host 221.252.29.22
22.29.252.221.in-addr.arpa domain name pointer usen-221x252x29x22.ap-US01.usen.ad.jp.
$ whois 221.252.29.22/e
(snip)
a. [Network Number] 221.252.29.16/29
あー、君は何をしたいの?実験? $ ntpq -p
remote refid st t when poll reach delay offset jitter
*ntp1.jst.mfeed. 210.173.176.4 2 u 432 256 172 16.667 0.036 0.442
+ntp2.jst.mfeed. 210.173.176.4 2 u 130 256 367 18.346 1.768 0.526
+ntp3.jst.mfeed. 210.173.160.86 2 u 120 256 377 16.608 0.537 0.984
LOCAL(0) LOCAL(0) 13 l 6 64 377 0.000 0.000 0.004 http://www2.nict.go.jp/dk/c272/news/index.html
sntp1.nict.go.jp IPv4:133.243.230.51 IPv6:2001:e38:2020::123
sntp2.nict.go.jp IPv4:133.243.230.52 IPv6:2001:e38:2020::124 怖いなこの板。(スレじゃなくて)
名前空欄にするとIPアドがでるのか。 >>334
それって各NTPサーバーはどうなるの?? http://www.jst.mfeed.ad.jp/others/04.html
うるう秒対応
時刻情報提供サービス for Publicにおける対応予定
2005年12月31日より、NTPパケット内におけるLeap Indicator(LI)のビットを「01」として配信いたします。うるう秒挿入の2006年1月1日9時になりましたら、この情報は解除されます。
Leap Indicator(LI)のビットをどのように解釈するかは、NTPクライアントソフトウェアの仕様をご確認下さい。
-----------
な対策をたいていの公開ntpサーバでやるんじゃない? ルーターにntp.jst.mfeed.ad.jpセットしたら2020年にされて切断されちまった windows用に、ntpdみたいに時刻を飛ばしたりせず、ちょっとずつ時刻修正してくれて、driftを計測して、同期がとれてなくても狂わない時刻修正ソフトはありませんか。 ntpdはWindowsでも動くけど、そう言う話ではない? DEODEO ENJOYインターネットのNTP鯖って公開されてないようだけど
桜時計でDNS鯖のIP(202.224.64.51)入れたらちゃんと時刻修正された。
でもnet time /setsntp:202.224.64.51してnet timeしてもタイムサーバが見つかりませんだって。
何故? >>342
net timeでパラメータを省略したときはWindowsネットワークで時刻合わせをしようとするから。
/setsntpしたなら、WindowsTimeサービスを走らせておけばいいだけ。
詳しく確認したければw32tmコマンドを使え。 >>286
個人的には,国際原子時の作成に関わっている原子時計直結=stratum 1
それらからGPSコモンビュー法等により校正をうけて原子時計直結=stratum 2
GPS同期はstratum 3だろうと思う.
まー結局のところ何にしろstratumにはたいした意味がないという結論でよいのだろうけど. んでも直結のマシンの温度管理がされてない場合はそこから+2くらいした方が 同一LAN内のst1に繋がっててもst2.
遠い外国のst1に繋がっててもst2. NICT、インターネット用時刻同期サーバによる日本標準時配信サービスを開始
http://japan.cnet.com/news/media/story/0,2000056023,20137847,00.htm
>処理能力は既存システム200台分以上に相当する毎秒100万リクエスト以上の性能を有する。
>この処理能力は世界最高性能で、現在の国内の需要を十分にカバーできるという。
NTPサーバアドレス ntp.nict.jp
WEBアドレス http://www2.nict.go.jp/w/w114/stsi/PubNtp/ >>351
tracerouteしてみるとSINET->CRL入り口->CRL内振り分け->NTPサーバ
とたどっているので,SINET内ならいいだろうけど,実際にはほとんどの場合においてmfeedの方が精度良く同期できそうな気がする。
確かにディレイ値はマルチフィードの方が安定してて1ms程早い。 ま、ntp.confに一行書き足して精度向上を図るにはいいかと。 >>278
福岡大学がNTPサーバのサブドメインドメイン名を変更して
初めて過負荷がわかった
という展開が面白かった
いや、むしろそうして欲しかった。
ntp.121ware.com
ntp01.rd-style.com >>361
mfeedのって、そこらへんのwindows利用者が桜時計あたりで指定しちゃってもいいものなの??
数百万台からのアクセスくらいなら、耐えられるかな >>364
もちろんOKだよ。
NICTに至っては、逆に歓迎してるし。 ntp.bbtec.net
219.188.200.128 C:\Documents and Settings\Owner>w32tm /monitor /computers:ntp.bbtec.net
ntp.bbtec.net [219.188.200.128]:
ICMP: error IP_REQ_TIMED_OUT - no response in 1000ms
NTP: -0.4046471s offset from local clock
RefID: ntp1.idc.ad.jp [158.205.237.70] C:\Documents and Settings\user>w32tm /monitor /computers:ntp.eonet.ne.jp
ntp.eonet.ne.jp [61.122.241.186]:
ICMP: 4ms delay.
NTP: +0.9360926s offset from local clock
RefID: ntp2.jst.mfeed.ad.jp [210.173.160.57] C:\Documents and Settings\IT_USER>w32tm /monitor /computers:ntp02.dion.ne.jp
ntp02.dion.ne.jp [210.251.0.16]:
ICMP: 22ms delay.
NTP: -28.9690637s offset from local clock
RefID: (unknown) [192.168.38.230] http://sea-mew.jp/nox/modules/rpms/searchntp.php
w32tm /monitor /computers:ntp03.dion.ne.jp
ntp03.dion.ne.jp [210.251.0.81]:
ICMP: 22ms delay.
NTP: -28.9690637s offset from local clock
RefID: (unknown) [192.168.38.229]
C:\Documents and Settings\USER>w32tm /monitor /computers:ntp-tk01.ocn.ad.jp
ntp-tk01.ocn.ad.jp [202.234.233.106]:
ICMP: 16ms delay.
NTP: +0.0936785s offset from local clock
RefID: (unknown) [203.139.161.118] C:\Documents and Settings\USER>w32tm /monitor /computers:ntp-tk02.ocn.ad.jp
ntp-tk02.ocn.ad.jp [202.234.233.109]:
ICMP: 16ms delay.
NTP: +1.8289252s offset from local clock
RefID: (unknown) [203.139.161.118]
C:\Documents and Settings\USER>w32tm /monitor /computers:ntp-os01.ocn.ad.jp
ntp-os01.ocn.ad.jp [210.145.255.76]:
ICMP: 7ms delay.
NTP: +1.7542622s offset from local clock
RefID: (unknown) [203.139.161.118] UPLOAD/DOWNLOAD が安定していれば'.jp'にこだわる必要がないはずで...
=====>>>>> RFC2030,RFC4330 をよーく読んでみよう !!!
それよりもっと怖いのは'.cn'からの大量のアクセスだったりして 保守&安定してるのを報告。
remote refid st t when poll reach delay offset jitter
==============================================================================
-ntp-os01.ocn.ad 202.234.233.104 3 u 39 1024 377 20.772 -17.566 0.702
-ntp-tk01.ocn.ad 202.234.233.104 3 u 14 1024 377 27.101 -17.723 0.977
-ntp-tk02.ocn.ad 202.234.233.105 3 u 4 1024 377 26.934 -17.784 1.339
-ntp1.jst.mfeed. 210.173.160.86 2 u 61 1024 377 28.078 -18.000 1.529
+ntp2.jst.mfeed. 210.173.160.86 2 u 53 1024 377 28.540 -16.982 1.012
+ntp3.jst.mfeed. 210.173.160.86 2 u 60 1024 377 28.181 -17.364 1.684
*ntp-b2.nict.go. .PPS. 1 u 67 1024 377 42.539 -12.766 3.397
LOCAL(0) .LOCL. 5 l 31 64 377 0.000 0.000 0.002
NICTとMfeed、OCN網内NTP参照。ホップ数はOCNからNICT/Mfeedともに+5くらい。
ただしOCN網内なのに四国からはMfeedと東京OCNのdelayって殆ど変わらんねw remote refid st t when poll reach delay offset jitter
==============================================================================
LOCAL(0) LOCAL(0) 10 l 18 64 377 0.000 0.000 0.000
*ntp-a2.nict.go. .PPS. 1 u 263 1024 377 30.060 0.891 0.248
-ntp-b3.nict.go. .PPS. 1 u 575 1024 377 30.101 1.451 0.000
+ntp-b2.nict.go. .PPS. 1 u 262 1024 377 33.004 0.784 0.000
+cherry.nagaokau .GPS. 1 u 586 1024 377 70.830 1.055 0.690
-ntp1.jst.mfeed. san-ntp1.jpnap. 2 u 797 1024 377 32.200 -0.968 0.000
-ntp2.jst.mfeed. san-ntp1.jpnap. 2 u 576 1024 377 24.966 1.304 0.000
#ntp3.jst.mfeed. san-ntp1.jpnap. 2 u 571 1024 377 35.010 -3.461 2.914
#ntp1.wakwak.com ntp1.xephion.ne 3 u 560 1024 377 25.402 0.305 1.038
#ntp2.wakwak.com ntp1.xephion.ne 3 u 138 1024 377 25.833 1.159 0.051
俺はringで十分だ。
塵も積もれば山となるで負荷は均等にしようぜ。
だからring サーバーとの距離が関係するからかな。
例えば九州から東京のmfeedを使うと往復の遅延は無視出来ない。
ringなら近くのntp鯖を利用出来るようになっていたかと。 http://ring.maffin.ad.jp/ring/ntp.html.ja
>tenbinを利用して、一番近いntpサーバへ誘導したりしないのですか?
>試験的に対応してみました。ntp.t.ring.gr.jpです。
>また、DNS Balanceを利用して、一番近いntpサーバへ誘導する試験サービスも行っています。ntp.dnsbalance.ring.gr.jpです。
ってあるけど、ntp.ring.gr.jpはどうしてるんだろうね? 電波時計のキット買ってきてシリアルあたりに繋いどけばキミもstratum1だ! 例えば北海道から関西の鯖を往復させたら無視できない数値と思うか
そんなもん端数だよと思うかどちらかだね。 C:\Documents and Settings\IT_USER>w32tm /monitor /computers:ntp02.dion.ne.jp
ntp02.dion.ne.jp [210.251.0.16]:
ICMP: 16ms delay.
NTP: +1.2064027s offset from local clock
RefID: (unknown) [192.168.38.230]
C:\Documents and Settings\IT_USER>w32tm /monitor /computers:ntp03.dion.ne.jp
ntp03.dion.ne.jp [210.251.0.81]:
ICMP: 15ms delay.
NTP: +1.2188257s offset from local clock
RefID: (unknown) [192.168.38.229] C:\Documents and Settings\admin>w32tm /monitor /computers:ntp1.eonet.ne.jp
ntp1.eonet.ne.jp [61.122.241.186]:
ICMP: 5ms delay.
NTP: -0.9969884s offset from local clock
RefID: ntp-a3.nict.go.jp [133.243.238.244]
C:\Documents and Settings\admin>w32tm /monitor /computers:ntp2.eonet.ne.jp
ntp2.eonet.ne.jp [61.122.241.187]:
ICMP: 4ms delay.
NTP: -0.9904510s offset from local clock
RefID: ntp-a3.nict.go.jp [133.243.238.244]