トップ 最新 追記

のろのろのろ雑記


2008年08月15日 [P2PQ][PC] p2pquake.ddo.jp サーバのBefore/After

_ [P2PQ][PC] p2pquake.ddo.jp サーバのBefore/After

 まだ変わる前なんだけど、調べたデータは残しておく。同じCeleronでも中身が違えばパフォーマンスもケタ違い、そしてなかなか省電力。

  • FUJITSU FMV-DESKPOWER MIX365(M9365) → NEC Express5800/110Ge
  • Celeron(Mendocino) 366MHz → Celeron(Conroe-L) 430 (1.80GHz)
  • SAMSUNG SV2046D (20GB) → HGST HDS721680PLA380 (80GB)
  • SDRAM PC66 128+64MB → DDR2-SDRAM PC2-6400 512MB

ベンチマーク

  • MIX365: CPU, HDD, MEM, NIC(PCI) のみ. VGA, SOUNDなどオンボード.
  • 110Ge: CPU, HDD, MEM, DVD, SOUND(PCI) のみ. VGA, NICなどオンボード. ダウンクロック済み(FSB:200MHz→166MHz)
項目 MIX365 110Ge 倍率
消費電力(力率1換算/エコワットによる) 37W 54W x1.46
CrystalMark 7256 35501 x4.89

2008年06月08日 [PC][Vista] DHCP サーバからアドレスを振ってもらえない

_ [PC][Vista] DHCP サーバからアドレスを振ってもらえない

 これに引っかかった。「DHCP サーバからの応答もブロードキャストで頼むよ」っていうBROADCAST フラグが「0でない (not disabled)」ことで問題が起こるらしい。

 Microsoft お得意の独自路線が悪いのか,実は仕様(RFC?)の範囲内でそれに従っていないルータが悪いのか,そこまでは調べてません。


2008年05月01日 Nagle アルゴリズム と 遅延ACK(Delayed ACK)

_ Nagle アルゴリズム と 遅延ACK(Delayed ACK)

 P2P地震情報のデータ到達時間を短くしようと調べていたら、 Nagle アルゴリズム と 遅延ACK という仕組みがあるらしい。自己中心的な解釈なので、あんまりアテになりませんが。

Nagle アルゴリズム

  • 細切れのデータをまとめてパケットにすることで、転送効率の向上を図るアルゴリズム。
  • データパケットを送信した後、次のデータ送信を以下のいずれかが満たされるまでバッファリングする
    • 送信したパケットのACKが返ってくる
    • MSS(MTU - 40)を超えるデータの送信要求が発生する
    • 200ミリ秒が経過する

遅延ACK (Delayed ACK)

  • ACKの送信をバッファリングし、他データとの同時送信による転送効率向上や、Nagle アルゴリズムの機能性向上を図る。
  • データパケットを受信した後、ACKの送信を以下のいずれかが満たされるまでバッファリングする
    • 次のパケットを受信する
    • 送信するパケットが発生する
      • ACKと送信するパケットをまとめることで効率化
    • 200ミリ秒が経過する

問題になるケース

リアルタイム性が要求される小さなデータを一方向に送信し続ける場合
  • Nagle アルゴリズムにより、小さなデータはバッファリングされる
  • 遅延ACKにより、送信パケットに対するACKを返してこない
  • その結果、データは200ミリ秒に1回まとめて送信される。
    • 改善策として、受信確認を返すようにする。
      • 遅延ACKの送信条件「送信するパケットが発生する」が満たされる。ただし、そのACKを受信するまでの間はやはりバッファリングされる(Nagle アルゴリズム)。
    • 別の改善策として、Nagle アルゴリズムを無効化する。
      • ACKを待たずに送信するため、バッファリングとそれによる送信遅延がほとんどなくなる。

…というわけで。

 P2P地震情報の通信で、これらが問題になっているケースもありそうです。データを連続送信するような機会は少ないので、確率としてはかなり低いと思いますが… いや、その低い確率でも遅延は問題だ。

 こういう面からのアプローチもなかなか面白いです(?)。


2008年04月29日 一般向けの緊急地震速報

_ [地震][解析][P2PQ] 一般向けの緊急地震速報

 2時32分25.1秒、発表。予測更新の過程で1度だけ「最大震度5弱程度」となったので一般向けの発表が行われたっぽい。

遅れ(遅延)の話

 放送・検出遅れは P2P地震情報の開発ログ(緊急地震速報 配信試験における、緊急地震速報の検出について) に記述。正直、気象庁〜NHK間は結構がんばってる気がする。

 チャイム音の検出に最低1秒は掛かるので、その後の配信をいかに短時間で行うかがポイント。発表から表示まで5秒掛かるようでは意味がないので、どうにかしなければ。

放送の話

 NHKラジオ第一にて。

  • 放送中の音声が突然中断し、無音となる。無音は約0.28秒続く。
  • チャイム音が流れる。
  • 「緊急地震速報です。震源は、○○○。次の地域は、強い揺れに警戒してください。○○、○○。」を2回繰り返す。
  • 「緊急地震速報でした。」
  • チャイム音が流れる。
  • 無音がしばらく続く。

 音声データの記録がここまでしかないので、無音の後は分からず。


2008年03月19日

_ ファイル破損

 サーバをNAS代わりに使っているのでしばしばネットワークトラフィックがえらいことになっていますが(グラフ振り切ってたらそれはすべてLAN内通信が原因)、エンコードの出力先に指定したら容量不足の遅延書き込みエラーでさらにえらいことになりました。

_ [P2PQ]地震感知情報データベース化

 地震感知情報をデータベース化すれば表示率改善がものすごく楽に出来ると思っていたんだけど、よくよく考えれば 感知度 や 割合 の値は1件受信ごとに再計算しているので、静的なデータベースにするのは難しいのでした。ちゃんちゃん。

 むしゃくしゃしたので再計算ごとにレコードを追加するようにしてやる。