時刻合わせ総合スレッド2

しかたなく２げと

3げとずざ

てかテンプレ入れ忘れ!

まとめWiki(移転先探し中): http://www.wikiroom.com/?%A5%D7%A5%ED%A5%D0%A5%A4%A5%C0%CA%CCNTP%A5%B5%A1%BC%A5%D0%A5%EA%A5%B9%A5%C8
ミラー?: http://wiki.nothing.sh/page/NTP

補完サンクス>3

>>1
乙

前スレ
時刻合わせ総合スレッド
http://pc5.2ch.net/test/read.cgi/linux/1008318869/

>>3
移転した模様
http://wiki.nothing.sh/page/NTP

stratum-2からのアクセスの調査結果

全パケットのうち、10%がstratum-2からのアクセス。
（分散できればトラフィックは激減することになる）

入りのパケットを上記のみに絞ってフィルターをかけると、再送が頻発し、
トラフィックが数倍に増加。
（inのみで6Mbps 予想されたことだが悲惨な結果）

よって
当面開放を続けて、皆さんの協力の結果を見守るほかないと思われる。

>>8
あんた一夜にして有名人になりましたな

ついでながら、こちらで見つかったstratum-2のマシンは
15000台弱
きっと近くに適当なNTPサーバが見つかるはず。

>>11
4のDNSに沢山書く方法でいけば簡単そうだけどね。
サーバ募集しとけば？

stratum1を公開している大学間で協力して
DNSの設定も上手くラウンドロビン出来るようにして
負荷分散するとか出来ないかな。
IPアドレス直打ちで来てるのは防げないけど。

>>10
そのIPを公開すりゃいいじゃん。
ついでに福大のDNSに登録すりゃいいじゃん。
pool.ntp.fukuoka-u.ac.jpとかでラウンドロビンすればいい。

ルーターとかカメラやＤＶＤレコーダーとか一見ＰＣでないネット製品に
デフォルト登録されているのが多いぜ。
これの対策も必要

fukuoka-uの椰子のホスト名やIPアドレスを含む記事は1000件ぐらいヒットした最寄り

でだ、

自分のところのntp負荷削減にとどまらず、今後の日本に於ける
ntpサーバの運用はどうあるべきか(研究・商用含め)の論文は
出すんだろな？>>8

まぁ自分が書かずに学生に書かせてもいいが、
結局「今協力している鯖管、網管」の努力には
ある意味報いてほしいと思うぞ。

大学の存在は外部から見れば「いかに有用な論文を書いてくれるか」が
一つの期待値だからな。

期待しているぞ>>8

あぁやっぱり再送でトラフィック増大ですかー
大学の引き込み回線の手前で遮断できない限りどうにもできなそうですね

でもそんな事できるのかな？

単にパケットをdropするのじゃなくて、
ICMPでdestination unreachableを返したら再送が減るってことはない?

とりあえず前スレを使い切りませんか? なんか同時進行になっちゃってますよ。

wikiリスト移転しますた
http://wiki.nothing.sh/page/NTP

旧リストに昼以降されてた修正が、新リストの方に反映されてない模様なので、
修正された方は再度新リストに反映ねがいまつ

>>8
おもうんですが、

１．現在の133.100.9.2 / 133.100.9.4 とは別のntpサーバを立てる（別IP)
２．新ntpサーバはstraum-2/1からのアクセス以外を遮断する(drop)
３．新ntpサーバはOpenAccessとはせず、なるべく公表もしない
４．旧ntpサーバの停止期限を公表する（各方面に）
５．旧ntpサーバを停止期限後に停止する
５の２．旧ntpサーバのホスト名をDNSレコードから外す。（正引きできないようにする）
６．直後再送トラフィックの増大が予期されるが、仕方ないので放置する
７．再送トラフィックが逓減するのを期待する

可能であれば、旧ntpサーバの属するサブネットを全部移転してしまう。
すなわち研究室の全マシンと新ntpサーバを移転先のサブネット
（もしくは、新ntpサーバは別のロケーションに置いたが良いかも検討要）
に移転し、旧ntpサーバの属するサブネットをnetwork unreachableにしてしまう
（ルーティングテーブルから外れるようにする）

てのはどうでしょう。荒療治過ぎる？

ISPのユーザサポートに問い合わせて「無い」って
言われたもののリスト（無理矢理見つけ出したもの）
は消したほうがいいんじゃね?

sntpとntpの違いって何？

YBBに問い合わせた所
NTP鯖は置いてないとの事
でも使っちゃおう

せっかくだから新スレ立てて来るか。

スレタイ：NTP, SNTP負荷分散作戦所
----
NTP サーバは、(ネットワーク的に)近くて、(ping応答が)早いサーバを選択するのが鉄則。
まずはプロバイダが NTP サーバを提供してるか確認しましょう。

おいそこの clock.nc.fukuoka-u.ac.jp 使ってる奴！とりあえず変更しよう。な。


関連wiki
http://wiki.nothing.sh/page/NTP
----

>>27
通信技術板かネットサービス板で

プロバイダー板に立てようか?

>>18
何この偉そうな粘着。キモ杉

>>29
ISPもルータメーカも絡むからどうだろう

問題への関与者

１．ルータ等メーカの無責任さ
２．管理者、設定業者の怠慢
３．乗り気でないISP
４．呑気すぎた某大学の中の人
さらに
５．無頓着に福大を参照させているウェブや書籍の記事

>>27
>>16にもあるけど、IPアドレスも併記したほうがいいんじゃね？

おいそこの clock.nc.fukuoka-u.ac.jp（133.100.9.2） 使ってる奴！とりあえず変更しよう。な。

んじゃ、通信技術板で立てます。
33の様にIP付けときます。

多分、親切心で言ってるんだとは思うけど、IP変えるとかFQDNの向き先を変えるとかは
現実的ではないことは判ってください。

Stratum1だからこそこういう事態になっていて、それゆえに管理者は「お願い」していて
それ以上のことは現状では求めていない訳ですよ。

ヘタなことをしたらサーバ・ネットワーク負荷の問題じゃ済まなくなりますからね。

今のところの対策は、福岡大学が結構手一杯なので、普通の人は近所のサーバに
つなぎ変えてくださいって啓蒙していくというのが理想でしょう。
いますぐどうこうというわけでもないのですから。

「警察庁まで行かずに近所の交番へ」とか「大学病院までいかずに近所の病院で」という
レベルのことだし、困ってるってことを話せば協力してくれる人も多いでしょう。

>>8
可能なら、1ヶ月くらいでどの程度軽減できたか、参考までに教えて頂けますか。
多分数パーセントだとは思いますが。
こういう時こそ2chを使って色々な人にお願いすべきってことの証明になるかと
思いますので。

全然関係ないんだが、ここは
E-mail 欄が正しい使い方されてる
貴重な書き込みのあるインターネットですね。

立てたよ。

NTP, SNTP負荷分散作戦所
http://pc5.2ch.net/test/read.cgi/network/1106498099/

テンプレ貼りは他力本願。

>>37 フシアナトラップのある板に。。。 orz

PCなどの時刻合わせに使われているNTP(Network Time Protocol）サーバの
草分け、福岡大学の「clock.nc.fukuoka-u.ac.jp」へのアクセスが増え過ぎて
しまい、管理者を悩ませているという。
http://headlines.yahoo.co.jp/hl?a=20050121-00000039-zdn_n-sci


これは既出かな

>>40 URL中の"zdn"は、itmdeiaの旧称zdnetのこと。

というか、検索くらい汁！
http://pc5.2ch.net/test/read.cgi/linux/1008318869/600
http://pc5.2ch.net/test/read.cgi/linux/1008318869/588

>>37
プロバイダー板の方が良くないか？

>>11 福岡大学の人がニュースリリース出すのが一番てっとり早いと思われ。

問題点は
Stratum2以上の公開サーバーが異常に少ないということだ

>>44
一個出来たぞw

sports2.2ch.net　stratum 2

>>45 それ、海の向こうじゃん…。
と思ったら、sports2だけは、国内にあるんでしたっけ？

>>46
whois 210.224.161.33

すんません、 ntpd で時刻同期してるんですが、
ネットワーク接続が切れると同期が取れなくなるみたいです。
ググってみたんですが、これという解決策も見当たらず
(前スレが引っかかった)

ちなみに ntp.log には

24 Jan 09:45:01 ntpd[2368]: sendto(210.173.160.27): Invalid argument

みたいな行が大量に残ります。
なんか設定とかで回避できるんでしょうか。
それとも再接続の度に ntpd 再起動?

ちなみに ntpd のバージョンは 4.2.0 です。

↓前スレ埋めてください（議論で）

時刻合わせ総合スレッド
http://pc5.2ch.net/test/read.cgi/linux/1008318869/

福岡大作戦の話は徐々に↓に移ってください（厨房避けのfusianasanの罠に注意）

NTP＠｀ SNTP負荷分散作戦所
http://pc5.2ch.net/test/read.cgi/network/1106498099/

>>50

厨房避けってか
ネットワークビジネス厨避けだったんだがな。

>>48
そんなモノです。
ntp.drift ファイルが出来てたら、それを元に補正はやってくれます。

でも接続が復活した時に時刻が飛ぶかもですね。
確か ntpd 起動時のオプションで回避出来た筈なんですが…。

あと sendto なエラーを減らすだけなら、minpoll を大きくしてやるといい筈です。
でも(接続が復活した際の)再同期の時間もかかりますね。
ntp.conf の iburst と併用するといいのかな？(やってみた事ないので分からん)

>>48
いあ、接続を回復したあともずっと同じエラーをはき続けるのです。
なので、一旦 ntpd を restart しないと二度と同期しません。はい。

>>55
なんか似た様な症状が報告されてますね。
ttp://lists.ntp.isc.org/pipermail/questions/2003-December/002360.html

自宅では ntpd は走らせてないので役に立てなくてｽﾏｿ

をを、なんだか自作自演してるみたいだ。
>>53>>56 の名前欄間違えました。orz

http://pc5.2ch.net/test/read.cgi/linux/1008318869/998
経路上の問題でntp鯖へのinパケットがSINETから来るって事じゃないかと言う稀ガス。
OCNも使っているみたい＞服代

接続構成はどうなってる? >>48

>おい、そこの clock.nc.fukuoka-u.ac.jp (133.100.9.2) 使ってるヤシ！
>とりあえず変更しよう。

その通り、ネットワークリテラシー的にもこのような参照先の局在化は避けるべきだ。











…まあ、俺は変えないけどな。貴重なstratum1だし。
お前らはせいぜい誤差の大きなst2でも有り難がってろ(ｹﾞﾗ

>>61
プ

Stratum1 が無条件で Stratum2 より高精度だと思っている人は、
mfeedの人のJANOG15での発表資料を読むことをお勧めする。

「インターネット上の高精度な時刻配信サーバの運用」(PDF)
http://www.janog.gr.jp/meeting/janog15/data/NTP-ito.pdf

>誤差の大きなst2

これはさすがにバカすぎだろ。

>>61
黙って自前でStratum1サーバを買え。
インターネット越しのNTPなどとは比較にならない精度が得られるぞ。
四畳半のアパートでもこいつなら大丈夫だ。
http://www.shoshin.co.jp/computer/endrun/cdma.html

...板違いですまん。

秋月のキットを使って自前のst1鯖を立てる方法、
みたいなwebページキボンヌ。

うちBフレで帯域余ってるからNTP鯖立ててもいいんだけど
できればst1にぶら下がったst2じゃなくて
clock sourceも自前で持つst1を立ててみたいのよ。

>>66
ちょっとぐぐって味噌、あるから

>>64
いちいち突っ込まなくていいよ
世の中バカの方が多いんだから

大きなStratumほど誤差が大きくなるのが普通なのは確か。
1つ鯖介すごとに誤差が大きくなるのは当たり前。
それは元になってるStratum1の鯖がまともな事が前提。
まともなのなんてmfeedの上位の非公開Stratum1くらいだろ。

>>69
確か……かなあ。

adjust time server xxx.xxx.xxx.xxx offset 0.005138 sec, delay 0.00000

上記のようにdelay 0.00000　ってなるサーバーがあるんだけど、どういうこと？遅れがまったくない？

>>69
何を基準に「まとも」かどうかを判断するの?

YahooBBユーザーですが、ntp.bbtec.netにtracertしたら
無駄に内部のルーター経由しまくってるんですが、他のISPの方もこんなもんですか？

1 21 ms 21 ms 20 ms YahooBB220*********.bbtec.net [220.***.***.***]
2 20 ms 20 ms 21 ms 10.36.8.71
3 22 ms 21 ms 20 ms 10.36.0.35
4 20 ms 20 ms 20 ms 10.36.0.43
5 20 ms 23 ms 21 ms 10.36.0.51
6 21 ms 20 ms 20 ms 10.36.0.59
7 20 ms 21 ms 20 ms 10.36.0.67
8 22 ms 20 ms 21 ms 10.36.0.83
9 22 ms 23 ms 23 ms 10.2.4.165
10 22 ms 23 ms 24 ms 10.2.128.141
11 30 ms 30 ms 29 ms 10.0.128.213
12 29 ms 30 ms 29 ms 10.0.129.222
13 29 ms 29 ms 29 ms ntp.bbtec.net [219.188.200.128]

>>73
私はWAKWAKユーザーでntp2.wakwakcomでこんなもん

1 3 ms <10 ms 1 ms 192.168.0.1
2 20 ms 13 ms 14 ms faw011.nw.wakwak.com [219.127.35.3]
3 20 ms 20 ms 13 ms flwest1g.nw.wakwak.com [219.127.35.1]
4 19 ms 45 ms 17 ms phgwdjm1g0-1-0.nw.xephion.ne.jp [211.132.135.221

5 20 ms 15 ms 14 ms phcrdjm1g0-2-0.nw.xephion.ne.jp [219.127.32.65]

6 26 ms 21 ms 20 ms phcrdnp1p5-0.nw.xephion.ne.jp [211.9.229.193]
7 21 ms 19 ms 19 ms phgwmrn1f3-0.nw.xephion.ne.jp [211.9.229.190]
8 25 ms 21 ms 22 ms ntp2.wakwak.com [211.9.227.25]

漏れは駅だけど、7hop ですよ

フレッツなんかの場合、ユーザには見えないレイヤにいくつか
ルータがあるだろうけど、Y!BBなんかだと生でルータが見える。
だからhop数が多いように見える、とかかな。

この職業について初めて触った Unix が EWS4800 で
初めて手に取ったバイブルが鶴岡さんの共著された
「EWSのシステム管理」でした。
見よう見真似で本に書いてあるとおり ntp.conf の設定をして以来
サーバ機には無意識で 133.100.9.2 と記述するのが習慣に
なっていました。

Stratum1 の負荷をかけてはいけない、というのは頭で分かっていましたが
悲鳴があがるまで実際に使いつづけてしまったということは
本当に申し訳なく思っています。

福岡大学さん、そして NTP の国内での先駆者である鶴岡助教授、
本当に今までありがとうございました。

hopsが多いかどうかはタイシテ重要じゃない
RTT及びその偏差が小さい事のが重要
dionからだと

remote refid st t when poll reach delay offset jitter
==============================================================================
210.147.240.67 .STEP. 16 u - 1024 0 0.000 0.000 4000.00
202.225.94.228 .STEP. 16 u - 1024 0 0.000 0.000 4000.00
133.205.241.67 .STEP. 16 u - 1024 0 0.000 0.000 4000.00
+210.138.174.45 202.232.0.1 4 u 173 256 377 11.658 -1.050 0.221
-61.122.112.135 210.173.160.87 3 u 42 256 377 12.749 -0.285 0.791
+61.122.112.136 210.173.160.87 3 u 32 256 377 12.704 -0.908 0.221
+61.122.116.184 210.173.160.87 3 u 26 256 377 12.245 -1.026 0.312
-211.9.226.25 211.9.226.9 3 u 30 256 377 12.396 -2.073 0.164
-211.9.227.25 211.9.226.9 3 u 166 256 377 12.431 -0.781 0.481
-210.251.0.16 192.168.38.230 2 u 162 256 377 12.540 -1.924 7.830
-210.251.0.81 192.168.38.230 2 u 176 256 377 12.704 -2.208 0.445
-202.224.32.4 202.224.53.11 2 u 25 256 377 11.320 7.865 0.160
-210.139.246.140 211.10.62.120 2 u 164 256 377 12.571 -4.199 1.266
143.90.130.103 .STEP. 16 u - 1024 0 0.000 0.000 4000.00
+219.164.211.129 202.234.233.106 4 u 181 256 377 12.026 -0.998 0.546
-219.164.211.137 210.145.255.76 4 u 32 256 377 12.233 -0.757 0.431
202.234.233.106 .STEP. 16 u - 1024 0 0.000 0.000 4000.00
202.234.233.109 .STEP. 16 u - 1024 0 0.000 0.000 4000.00
210.145.255.76 .STEP. 16 u - 1024 0 0.000 0.000 4000.00
219.188.200.128 .STEP. 16 u - 1024 0 0.000 0.000 4000.00

% ntpdate sudo ntpdate ntp1.plala.or.jp
25 Jan 14:48:50 ntpdate[2833]: step time server 219.164.211.129 offset -32396.908407 sec

何でこんなに狂ったんだろう・・・

>>73
YahooBB の外に traceroute かけたら
もっと多くなるんじゃないの?

>>79
-32396秒＝-約540分＝-9時間

GMTになってたってことか・・・
原因わからんけどまぁいいや。

>>81
それで解ってくれるかなぁ

かぶってたorz

開始当時からずっとmfeedのお世話になってきたのだが、
ずっと10ms前後で安定していたdelayが、今週はバラツキ
が大きく60ms位まで延びたりする。
福岡大からの移行組が増えてる？

mfeedは当初の予定ではすでに実験期間が終了してるはずなんだけど。
どうなってんの？
正式に継続決定？

>>82
マシンのハードウェアクロックをGMTにするかJSTに合わせるかの設定が
おかしくなったんじゃ？

>>86
前スレに直リンされてたpdfに同じIPアドレスで正式サービス化するとか書かれていた。

>>85
http://www.jst.mfeed.ad.jp/s2html/27-delay-17.html
これかい?

>>88
>>63 の p.41 かい?

>>89
これは、Stratum1に対するdelayじゃないかい？
どっちにしろ、今週はアクセスが増えているんだろうな。

>>69
stratum-nとstratum-(n+1)の間のネットワーク品質が良ければ誤差は気にするほどもないはず
stratum3~4あたりでもミリ秒単位のオーダになるはず
で必ずしも上位stratumの鯖が正確とは限らないことは↓でガイシュツ。レスもガイシュツ。
http://www.janog.gr.jp/meeting/janog15/data/NTP-ito.pdf

>>73
ルータはツリー構造でntp stratumを構成していると思う。
ルータはNTP鯖として多数アクセスに耐えられるようにはなっていないはずなので、
多数ユーザが参照するべきではない。

>>85
ｎｔｐ１・２・３と３台もあるのにねぇ。１を使う人が多いのは予想できたこと。
なんで分散しないのかね。１以外を選んでいる俺は勝ち組。

>>93
なんでそんな話になったんだ?

>>95
ただ、ntp.bbtec.netがルータかどうかは知らない
公開NTPサーバとして専用機を割り当てているような環境でないと、ISPのネットワークに及ぼす影響は未知数になる。

>>85
まさにあちらを建てればこちらが立たず状態になっているな

>>94
3つ全部指定すればうまくやってくれますよ。

ここは鯖用途の多いLinuxの板だからかもしれんが
非公開の完全個人用途ならmfeedのうち一つだけで良いと思った。

前スレのdatのハッシュです。
Modify: Mon, 24 Jan 2005 15:25:52: +0000 (GMT)
md5sum: 5fd5adec63086dc0120e04d068565430
sha1sum: 9bc513a2eacf0dafa2c20ddae89c410d75f29604

http://internet.watch.impress.co.jp/cda/event/2004/12/02/5628.html
>DNSから情報を削除する方法を取りやめ、ACCSへの攻撃パケットを
>廃棄するための「Blackholeアドレス」を複数のプロバイダーで用意し、
>ACCSのDNS情報をこのBlackholeアドレスに書き換えるという対処を行なうことにした。

このBlackholeアドレス借りればいいじゃん。