ついに 1MBps の壁が見えてきた．ipq しっかりしろよ．
http://kakaku.com/bb/speed.asp
測定日時 ：2010/06/19 11:54:43
回線種類 ：光(ホーム)
回線名称 ：NTT フレッツ光/Bフレッツ
プロバイダ：その他
下り速度 ：1.3M(1,310,285bps)
上り速度 ：4.0M(4,011,110bps)
RTT 調べてる
がんばって libpcap 叩いて，tcpセグメントの遅延を引っ張り出すスクリプトを書きました．昨晩0時から朝までの遅延を拾ったので，いま解析中．さすがにテキストにダンプしてしまったので重たいのです…．
調べた
昨日のTCPのRTTを伝えよう…．
19日 0時〜1時
19日 1時〜2時
19日 2時〜3時
19日 3時〜4時
19日 4時〜5時
ご存じの通り(ご存じじゃねぇよ)，TCPというものは，エンドエンドで再送処理をしてくれるコネクション型のプロトコルです．回線処理速度に合わせて，エンド間で送信データサイズを調整したりして，オーバーヘッドを少なくしたりするイカしたやつなのです．
このグラフは，我らが IPQ 経由で，ftp.ne.jp にあるデータをDLしているとき，我らが Linux サーバの NIC を監視して得られました．
具体的には下記のようにして拾っています．
- 相手サーバから送信される TCP シーケンス番号とデータサイズを監視して，そのときのタイムスタンプを記録．
- (うちのサーバが続きを相手サーバに要求)
- 相手サーバから送信される 続き物のセグメントの TCP シーケンス番号は，1. のTCPシーケンス番号＋データサイズになっているので，これを発見したら，タイムスタンプを記録．
- 1. と 3. の差分を出力．
ですので，2. の処理が混ざりますので，正確な RTT とは言えませんね．ただ，うちの サーバ も10年前の PC というわけでもないし，ほとんど誤差の範囲だと思います．
あと，あくまで1セグメントをもらったときにかかる時間だということも考慮しなくてはなりません．ですから，RTT が大きいとかそういうことを主張したいわけではなくて，バラツキが激しすぎるといいたいわけです．
なお、一発で通れば、RTTは0.1秒ちょい程度なのですが，再送やらなんやら入って0.3秒程度となり，さらに再送すると，0.7秒，1.5秒と増えていきます．スカスカなときは，ほとんどのセグメントが0.2秒以内になります．まぁ，上で述べてるとおり，TCP の RTT 云々じゃなくて，バラツキがきになるんですけどね．
日曜の晩はスカスカ．金曜の晩と土曜のお昼は激込み
日曜日の晩はスカスカ．月曜日は仕事があるんだろう．どうやら IPQ のヘビーユーザの方々もちゃんと職を持っておられるようだ．ぼくといっしょだ！！
http://kakaku.com/bb/speed.asp
測定日時 ：2010/06/21 02:28:26
回線種類 ：光(ホーム)
回線名称 ：NTT フレッツ光/Bフレッツ
プロバイダ：その他
下り速度 ：45.5M(45,544,366bps)
上り速度 ：44.3M(44,317,379bps)
