のろのろのろ雑記

_ [地震][PC] ウェザーニューズ(WNI)の「The Last 10-Second」が大変なことになって"いた"件

　先日 ウェザーニューズ(WNI)の「The Last 10-Second」が大変なことになっている件 と題してサービスのサーバがいっぱいいっぱいであることをお伝えしましたが、どうやら改善されたようです。

• WNIのLastなんちゃら監視所

　9月29日17時30分を過ぎたあたりで、サーバ数が18から39と約2倍になっています。そして、利用者の接続が各サーバに分散したのか、全サーバで "(・∀・)イイ" 表示になりました。

　これだけ増えれば、利用者の多い時間帯でも大丈夫でしょう。ああ、でも20分おきに切れる現象は直ってるんでしょうか？

_ [地震][PC] ウェザーニューズ(WNI)の「The Last 10-Second」が大変なことになっている件（→なっていた件）

　※2008年9月29日追記：9月29日17時30分ごろ、WNIのサーバが約2倍に増強されました。全サーバに余裕が生まれ、スムーズに接続できるようになっています：ウェザーニューズ(WNI)の「The Last 10-Second」が大変なことになって"いた"件

　※2008年9月21日時点の不確かなデータに基づくものです。一切の正確性・最新性その他を保証しません。

　ウェザーニューズの緊急地震速報サービス「The Last 10-Second（L10SまたはTLTSとも）」が大変なことになっているらしい件。

まとめ

• 頻繁に（20分おきに）切れて、なかなか繋がらない。
  • 頻繁に切れる原因はよく分からない。
  • なかなか繋がらないのは「WNIのサーバがいっぱいいっぱいだから」。

• 20分おきに2分切れる場合、「緊急地震速報を受信出来ない時間」が9.1％発生！
  • 防災目的でマジメに使う場合は、改善を求めるか他サービスの利用を考えるべし。

現象

　私はサービスを使っていないのですが、サービスを使う人曰く、

• 20分おきに切れる
• ログを見ると『Try connect』が複数回続いて『Communicating』になる

　とのこと。つまり、頻繁に切れた上になかなか繋がらない（接続が回復しない）ようです。

サービスの仕組みと原因

　詳しい人に調べてもらいました。私自身は未検証です。

1. HTTPでサーバリストを取得、リスト内のサーバへHTTP接続・認証
2. 認証後は、定期的に接続確認のための通信と、緊急地震速報の通信が行われる

　という仕組みだそうです。ダウンロードページのシステム要件にも"HTTPアクセスが可能なこと"とありますが、おそらくプロキシのある環境での利用を考慮しているのでしょう。

　で、定期的に接続確認しているんだったら切れないだろうと思うのですが、「突然切断処理が行われる」らしい。

　さらに、その後繋がりにくい現象については、次のように言われました。

1. サーバへHTTP接続・認証するとき、「セッションが限界だ」と言われて、
2. 取得したサーバリスト内の別のサーバを選択し、やり直す

• この「やり直す」のが何度も起きている

　つまりは、「たくさんのサーバの中で、接続できるサーバを何度も何度も探しているから時間が掛かる」のを「繋がりにくい」という風に感じていることになります。

で、どれくらい繋がりにくいの？

　…と言ったら、しばらくしてアドレスが返ってきました。

• WNIのLastなんちゃら監視所

　「(・∀・)イイ」が接続できるサーバの数、「（´・ω・`）ショボーン」が接続できない（セッション限界）サーバの数で、グラフの青と赤にそれぞれ対応しているとのこと。ここの1週間分のデータをグラフにしたものが最初の画像です。

　夜間帯を見ると「(・∀・)イイ」が0になっていて、ほとんど接続できない状態になっているようです…　接続リトライが行われるので厳密には「時間が経つと繋がる」ようですが、これはほぼ限界に近いのではないでしょうか…

対策

諦める

WNIに改善を求める

　免責事項や利用規約に「こういうことが起きても知らないよ」と書いてあるかもしれませんが。

複数のマシンで使わない

　※そういう仕様になっていたら読み飛ばしてください。

　1アカウントにつき1台でのみ使用し、サーバにやさしい会員になっておく。そして、WNIがサーバ増強を予定していることを期待するというもの。

他のサービスを使う

　「OCN緊急地震速報」や「緊急地震速報 フレッツタイプ」を使う。どちらもIPv6マルチキャストを使用しているので、少々コストが掛かるものの配信遅延はきわめて小さい。サーバの障害耐性は不明。

P2P地震情報の緊急地震速報 配信試験（オープンβ）を使う

　P2P地震情報の「緊急地震速報 配信試験（オープンβ）」を使う。無償で使える一方、「一般向け緊急地震速報の『発表』」しか分からないし、6秒くらい遅延するしで他サービスより大きく劣る。

　というわけで、エロイ人ありがとうございました。

_ [ColdFire] ColdFire×P2P地震情報(10) よし，サーバに送りつけよう

　Interface 9月号付録基板を使い，P2P地震情報のサービスを作ってしまう勝手な企画です．過去の記事は，タイトルのColdFireカテゴリからどうぞ．

オーバーサンプリングで効果的にノイズ除去できるのか？

　そういえば，オーバーサンプリングをすることでノイズ除去できるかどうか調べていませんでした．ということで調べました．

20 Hzサンプリング

20 Hzサンプリング，20サンプル移動平均をオフセットに，3サンプル移動平均をデータに用いた．

100 Hzサンプリング

100 Hzサンプリング，100サンプル移動平均をオフセットに，15サンプル移動平均をデータに用いた．

　もとになるデータは気象庁の加速度データ．フィルタを通した時の最大加速度と計測震度との関係を近似式として算出して用います．

20 Hzサンプリング時

0.7968 * Ln(最大加速度) + 0.9717

100 Hzサンプリング時

0.8055 * Ln(最大加速度) + 0.9568

　劇的な効果とは言えませんが，震度換算で0.6ほどノイズが減りました．うーん，もっと減ってくれてもいいんですが…

　ノイズで悩んでばかりでは進まないので，これ以上は後回しにしてさっさと作りましょう．

よし，サーバに送りつけよう

　ColdFire×P2P地震情報(8)で実装方法をあれこれ悩んでいましたが，結局『集計サーバに取得値をそのまま送りつけて，震度を計算してもらう』ことにしました．

• より小さな地震を検出できる
• ネットワーク化して情報を活用できる
• P2P地震情報の各情報もやり取りできる

　こうしたメリットは大きいです．「ネットワークに依存する」というデメリットがありますが，切断時には単独動作するようなモードを設ければ良いでしょう．

通信仕様を決めよう

　実装する前に，通信仕様を決めましょう．

• 加速度センサの値を送信して，震度換算値を取得する
  • データ記録，集計，公表はサーバ側で行う
• 地震情報や津波予報の概要，緊急地震速報の発表情報を取得する
  • 都道府県などによって送信条件を指定できるとよい
• ColdFire基板（SilentC）専用にならない程度に，実装が楽になるような何か

　ということで，暫定仕様をでっち上げました．SilentCで実装する以上，仕様を隠す意味はどこにもありませんので，この辺に置いておきましょう．

EPSP ColdFire Gateway（EPSP-CFG） プロトコル仕様 Ver.0x01

• クライアント-サーバ型，サーバはP2P地震情報（EPSP）ネットワークとのゲートウェイも兼ねる
• データ量の小さいバイナリプロトコル
• 加速度センサの活用と諸情報の受信機能

　次回以降，この仕様をもとに実装していきます．

参考

• http://www.seisvol.kishou.go.jp/eq/kyoshin/jishin/index.html

_ [ColdFire] ColdFire×P2P地震情報(9) 熱にご注意，SilentCベンチ

　Interface 9月号付録基板を使い，P2P地震情報のサービスを作ってしまう勝手な企画です．過去の記事は，タイトルのColdFireカテゴリからどうぞ．

　今回は，加速度センサやSilentCの気になるところを調べてみました．

熱にご注意

　P2P地震情報の中の人から「加速度センサの値って熱の影響受けやすいみたい．実験したからデータあげる」と言われたので，データを見てみました．ドライヤーで加熱したそうな．

　って，変わりすぎ！　データシート，データシート…　加速度センサのデータシートでは，0 gの感度差は±2.0 mg/℃，感度差は±0.03 %/℃が仕様とされているようです．いや，緑色のX軸は明らかにその範囲外．温度センサを付けていなかったので，温めすぎた可能性も否定できませんが．

　しかしながら，このような緩やかな変化は移動平均を使ってオフセットを出せば概ね解決します．問題になるのは，熱でノイズが増すかどうか．X軸のFFTを出してみました．

　ドライヤーを入れる前が平常時，入れた後が加熱時，入れてしばらく経ったのが過熱時です．平常時と比べると，加熱時，過熱時はノイズレベルが1段，2段ほど増えていることがわかります．

　ドライヤーの風による影響も含まれていると思いますが，同じ風量を当てた「加熱時」と「過熱時」とでノイズレベルに差があることから，ドライヤーの風だけではなく，熱（温度）が関係していると言ってもよいでしょう．

　つまり，ノイジーな状態を緩和するには，基板の熱対策も重要になってくる…　かもしれない，ということです．データシートきっちり読める人，人柱実験が大好きな人を募集しています（？）．

SilentCベンチ

　SilentCはインタプリタです．"filename::funcname"という風に別ファイルの関数を呼べるのは大変便利ですが，パフォーマンスが心配になります．せっかくなので，調べてみましょう．

main(){
 char c,soc; int i;
 //事前処理が必要な場合はここ
 c=CreateTimer(0,30000,0);
 for(i=0;i<10000;i++){
   //計測したい処理
 }
 PrNum(GetTimerCount(c));
 CreateTimer(c,0,0);
 //事後処理が必要な場合はここ
}

　"(30000-出力値)*10/10000"と計算すると，処理の所要時間がms単位で出ます．ただし，forループの処理時間を考慮しなくてはなりません．予めループ内に何もない状態で計測を行い，それをループ処理そのものに掛かった時間と仮定して一律差し引くようにしました（0.4543 ms）．

　なかなか面白いところがありますね．

• 関数を呼び出す場合，同じファイルの末尾に書くよりも別ファイルの先頭に書いたほうが早い．
  • 上から 別ファイル1行目の関数呼び出し，同じファイル末尾の関数呼び出し，同じファイル1行目の関数呼び出し です．
• メモリマップドI/Oなどでポインタを使って読み書きする場合，"pointer[0]=0;"を"*pointer=0;"とすると約2倍早い（箇所は限定される）．
• 途中で終了するための入力チェックは結構重たい．UDPの受信チェックなんかはさらに重たい．
• 値を10進数で書いても16進数で書いてもあまり変わらない．バイト数の関係か，10進数で書いたほうが気持ち早い．
• 除算はビットシフトのほうがやや早いが，数値で書いても遅くはない．

参考

• http://www.freescale.co.jp/pdf/MMA7360Lr1.pdf
• http://www.freescale.com/files/32bit/doc/data_sheet/MCF52235DS.pdf

_ [ColdFire] ColdFire×P2P地震情報(8) 実際どこまで出せるのか

　Interface 9月号付録基板を使い，P2P地震情報のサービスを作ってしまう勝手な企画です．過去の記事は，タイトルのColdFireカテゴリからどうぞ．

前回のまとめ

• A/Dコンバータへ直接アクセスして，"33.3 Hzの壁"を超えました．

実際どこまで出せるのか

　A/Dコンバータへ直接アクセスすることで，どれくらいまでオーバーサンプリング出来るでしょうか．

直接送信

main()
{
char soc;
char *ctr;ctr=0x40190000;
int *dat; dat=0x40190012;
int *sd=MemoryAlloc(8);
soc=CreateSocket(0);if(soc<0){PrStr("Soc!");return;}
Bind(soc,6909,0);sd[3]=3338;
PrStr("START!\r\n");
for(;;) {
  if(Getc(0)!=0)break;
  *ctr=32;
  sd[0]=dat[4]>>3;sd[1]=dat[5]>>3;sd[2]=dat[6]>>3;
  SendTo(soc,0xc0a80b69,6909,sd,8);
}
PrStr("GAME OVER\r\n");
CloseSocket(soc);
}

　取得値をそのままUDP送信した場合です．表示を見ると，258.56 Hz出ていることが分かります．

フィルタ送信

main(){
  char soc; int i,j,index,ind_n;
  int *sample=MemoryAlloc(600); long *nr=MemoryAlloc(12); long *offset=MemoryAlloc(12);
  int *data=MemoryAlloc(8); char *k; int *a;
  k=0x40190000; a=0x40190012;
  // init
  soc=CreateSocket(0);if(soc<0){PrStr("Soc!");return;}
  Bind(soc,6909,0); data[3]=3338;
  InitAd(0x70); index=0; ind_n=85;
  for(i=0;i<3;i++){offset[i]=0;nr[i]=0;}
  for(i=0;i<300;i++)sample[i]=0;
  // loop
  #stop 0
  for(;;) {
    if(Getc(0)!=0)break;
    *k=32;
    index=(index+1)%100;ind_n=(ind_n+1)%100;
    for(i=0;i<3;i++){
      j=i*100+index;
      offset[i]-=sample[j];nr[i]-=sample[i*100+ind_n];
      sample[j]=a[i+4] >> 3;
      offset[i]+=sample[j];nr[i]+=sample[j];
      data[i]=nr[i]/15-offset[i]/100;
    }
    SendTo(soc,0xc0a80b69,6909,data,8);
  }
  MemoryFree(sample);MemoryFree(nr);MemoryFree(offset);MemoryFree(data);
  CloseSocket(soc);
}

　移動平均によるフィルタを掛けてUDP送信した場合です．Unsignedで受け取ったので値が大変なことになっていますが，それよりも問題はサンプリング周波数．41.15 Hzと，先ほどの6分の1くらいしか出ていません．

　やはり，インタプリタで行うには限度があるようです．

どうしようか

　"あくまでSilentCで"ということで考えると，次のような方法があります．

• 集計サーバに取得値をそのまま送りつけて，震度を計算してもらう
  • データ量は 6bytes * 100 Hz = 600bytes/s = 4800bps
  • インターネットごしにUDP送信するのか？　TCP送信だとこんな速度出るのか？
• LAN内のパソコンに送りつけて，震度を計算．ないときは低いサンプリング周波数で単独動作
  • 切り替えをうまくできるだろうか？
  • 単独動作時の低いサンプリング周波数によるノイジーな状態を許容できるだろうか？
• 30 Hzや40 Hzくらいで，今までよりはマシにする
  • そんなに変わるだろうか？

　しばらく悩むことになりそうです．