カウントダウン

全体の大改修がある程度片付いた。
サーバー、クライアントの関係がおかしかったところを含めてごそっと修正。
並行サーバーのUDOPを書く必要が生じたが、そんなに難しいもんじゃないので問題ない。

いよいよ完成が見えてきた。
何事もなければきっと来週中には動く、はず。

SPADE HACKS3

[今日のまめちしき]
「Sourceオペレータ、stcpモードでは、
一度に一つのクライアントとしかデータ転送ができない。

ただし複数のクライアントと接続することだけは出来る。というか繋がる。」

……難しいですね。

EC2インスタンスの起動・リモート操作

Rubyスクリプトで自動化完了。
この後、Solverの結果によって起動・停止を制御するようにすれば
CloudManagerは実装完了。

そろそろすべてのコンポーネントが出揃う。
風邪引かない程度に注力する。

ポート 続

メモ。

131.112.12.*のサブネットは、ウェルノウンポートの一部以外は常に閉じている。
先日のページは間違い（私たちにとっては）

米崎研究室の萩原（注:HAGIHARA）助教がサブネットの現在の管理者。
メールで相談したところ、一時的にファイアーウォール外のIPアドレスを
提供して頂けることに。やったね。

これで実験環境が大分シンプルになった。


ところで、最近の語学学習状況に関して。
最近はそんなに考えなくともテキトーに英語で喋れるようになってきましたが、
代わりに単語や文法を間違う頻度がものすごく上がって困りもの。

・頭で文章作ってからでないとしゃべれない
↓
・文章作らなくても英語でしゃべれる（ただし間違い多し）　←今ココ？
↓
・英語でしゃべれる（間違い少なし）
↓
・英語でしゃべれる（流暢に）

こういう成長段階だと、こちらとしては都合がいいんですが。
どちらにしろもう少し落ち着いて話せってね。

それと、一部の人の英語が全く聞き取れなかったりするのも、
過渡期的な症状なんでしょうかね。
ベルリッツでは毎回講師が変わりますが、
講師によって結構聞き取りやすさは違います。
アメリカ系のネイティブ（＋早口）が天敵です。いいのかそれで。。。
カナダ系、フランス系、日系（といっても帰国子女というか向こう育ち）はそれ程でもないんだけども…

ポート

めも。
研究室からEC2のVMの間には、東工大ファイアーウォールがあるので。

http://portal.titech.ac.jp/ezguide/sslvpn.html
おそらく下図のポートしか通信には使えない。（他が塞がれてるはず）
まぁ少なくとも4つ程度は使えそうなので支障は無い…かも。

全体ミーティング終了

よって実装作業に戻る。


論文紹介の件、時間が限られた中でどうインパクトを持たせるか、
についても考える事は多そう。
まずはモノを作る。それと一定量の実験が必要か。

卒論についてはとりあえず置いておいて、
まずはSACSISの論文をどうキッチリ作るかを念頭に動くか。
それが早めに終わればCloud2011が出来る。
てか早めに終わらせないと間に合わない。ひいぃ。

スレッド禁止状況下におけるTCP accept() のタイムアウトについて

UDOP内でTCP通信をしたい場合の話。
基本的に、Initializeでコネクションを張って、
ProcessInputで送受信を行う流れになる。

ここで、TCP通信における accept() 自体は、クライアント側から connect() が来るまで待ち続けるようで、
これでは何らかの理由でノード側が落ちているとき、何時までも（少なくとも長時間）待ち続けるためにUDOPの初期化が終わらず、全体として動作が始まらない。
※Sumbitはできるが処理自体は行われない模様。

そこで、 accept()にタイムアウト機能を設けたいモチベーションが生まれる。
方法としては、accept()をする前に一度select()を使って接続を行ない、
（こっちにはタイムアウト時間が指定可能。）
接続があった場合に初めてaccept()を行う。今のところこれで動作を確認。

これは新たにコネクションを張る場合にも応用可能。


さてさて、不安だった要素技術も大分片付きつつある昨今。
コマンドを受け取ってノードの増減を行う処理の部分は、
SPADE部分は西井さんのStreamSRを参考にすれば良さそう。

確実にひとつづつ進めていこう。

SPADE HACKS2

StreamManagerの雛形が実装完了。
UDOP側でTCPコネクションを張って、ノード側にタプルを転送するのに成功した模様。
次は複数コネクションの管理、追加・削除をやればおおよそ完成。

UDOP豆知識。
Init的な関数が終了するまで、他のオペレータは動作しないみたい。
例えばUDOPが初期化中にエラーで止まってて、
他にSourceオペレータが存在する場合など。注意。

もうひとつ。
monitor Nil := ストリームほにゃらら
これは通らない。
monitorは出力タプルの監視をするから？

SPADE HACKS

stream Stream1( text : String )
stream Stream2( text : String )
  := Source()[ <ほにゃらら> ]{} -> node( <ちょめちょめ> )

こういう書き方しても、コンパイルで警告・エラーは出ず、実行可能。
ただし正常に動作しない気がする。

この場合、実際のデータフローはStream2の方に割り当てられ、
Stream1は何の処理もしないノード（つまりエッジなしノード？）として解釈されるみたい。
というか前方宣言？その割にはStream1の本体がなくてもコンパイル通るってどうなのよ。。。
暇があったらループするデータフロー作ってみて試してみよう。

良い子は真似しないこと。

その２。
Nil := Sink( ほにゃらら )["stcp://127.0.0.1:/", nodelays, csvformat]{}-> node( ほにゃらら )
これはコンパイルは通るが動作しない。

Nil := Sink( ほにゃらら )["stcp://thishost:/", nodelays, csvformat]{}-> node( ほにゃらら )
これは正常に動作する。

良い子は以下略。


まだまだ出てくるならホントに執筆しますよﾁｸｼｮｰ

実装フェイズ

とりあえず実装のタスクリストは切り出し完了。
何事もなければ一月と少しで終わりそう。それが理想。

ということで、各コンポーネントごとに片付けていこう。

IC2010終了

なんというダイレクトアタック（学生賞の副賞）。。。
上野さん受賞おめでとうございました。

こちらもWIPセッションで無事発表終了。
あまり突っ込んだ質問が来なかったのでしょんぼり。説明悪かったかしらん。

しかしただスライドと一緒にマシンガントークしても芸がないので、
今後はスライド1枚につき一つくらいは決め台詞を入れてみましょうかね。
「そう、〇〇ならね」「魔法のような〇〇」「革命的な〇〇」

それは冗談としても、プレゼンのスキルは重要ですね。
でもそこはスキルなのかはてさて。

こうだいさい

工大祭準備が無事（？）滞りなく完了しました。
研究室の皆さん、ご協力ありがとうございました。

あとは卒論をきっちり仕上げれば、心置きなく出ていけますかね（先の話）。
しばらくは目先のことに集中。たまにはそれも良い。

Tweetビューワ

現在換装中。明日中に適当に仕上げる予定。
しかしなにやら通信部分でゴダゴダしているようで、
いまいち安定してくれない。

一部マルチスレッドにしていたが頭がおかしくなりそうなので、
パフォーマンスを捨てて一旦スレッドをまとめて逐次処理に。

ある種、いつものこととはいえ、困ったものです。

最適化問題 考3

Twitter解析はデータ並列型に分類されるとおもいっきり突っ込まれてしまったが、
落ち着いて考えれば同じ要領で定式化に成功。

レイテンシに関しては決め打ちを狙うのが有効だった模様。

問題がなければ次こそ改めて実装フェイズに…？

最適化問題 考2

アプリケーションの種類を区別してトラフィック項を固定したのは正解だった模様。
レイテンシを最適化問題から除外し、
「次の予想レイテンシを、SLAギリギリ（ここは幅持たせてもいいけど）に固定」して決め打ちすることで、コスト最小化問題を線形計画の範囲内で記述出来た。
只今説明用資料まとめ中。明日には間に合うか微妙。

今のところ考え落としはない様子なので、
この調子ならSystemSで実装→仮パラメータで動作確認→事前実験で正確なパラメータ取得→本実験（結構これが多そう）、までの見通しが立つ。
実装コストは、SystemSの仕様などに振り回されない条件で、（それと界王拳使って）1ヶ月あれば凡そ片付くのではないかと見積り。EucalyptusのAPI呼び出し、各種設定等は追々再チャレンジ（先生の設定を利用しつつ必要な部分だけ）。今度は下手に粘らない。

これで流れが向いてくるといいけども。さてどうなることやら。

最適化問題 考

アプリケーションのタイプの分類を行ったことで、
ストリームデータの分割、それに伴うトラフィック課金の問題はどうにかなりそうだが、
代わりにレイテンシの方が複雑になってしまった。。。

「いくつそのVMを使うか」までを変数にして、
二値整数計画法に持ち込めばなんとかなりそうな気配だが、
クラウドリソースの上限を明示しないといけない上に、
上限が多すぎると変数の数が膨大になってsolve時間が発散しかねない。。。

レイテンシもレイテンシで、データ送受信に要する時間と、
実際の処理時間のどちらが大きいか（相当差があるなら片方を無視できる）
の点も考慮する必要があるかも。

そろそろどこかを近似するor最適化問題から除外しないと埒が明かないか…？

TopCoder

TopCoderというプログラミングコンペにおもむろに参戦決意。
http://www.topcoder.com/tc

http://news.livedoor.com/article/detail/4112394/
結構有名な？コンペみたいです。
週一程度で開催されるICPCみたいなものでしょうか（よく知らない）

miyuruさんも参加しようかな？とのこと。
私にとっての初回は二週間後の様子。
工大祭の準備（とIC2010の準備）は早めに終わらせておこう。

まぁ簡単に上位に行けるような腕じゃないので、
気楽にやってみようそうしよう。



しかし一番の収穫は、registerの英語にそんなに悩まなくなったことか。
大分慣れてきました。英語。下手くそですけども。

StreamCloudミーティング記録10/4

線形計画問題への落し込みと格闘中。
やはり実際にコード（数式）にしてみるといろいろアラが見えてくるものだ。
時間課金とレイテンシの項は、仮パラメータだがとりあえず落とせた模様。

ネットワークトラフィックに対する課金の項だが、
流れるデータストリームの分割量は各インスタンス数（つまり求める変数）に依存するので、
このへんを加味すると線形計画問題にならない。二次式になる。

選択肢は二つで、プロバイダを1つに絞るか（するとトラフィック課金は最適化問題から除外される）、
もう少し考えるか。
今週はもう少し考えることにする。その傍らで工大祭のポスターとかをやっつける。

//-------------------------------
ついでに話題に出た留学云々についても雑感を。

「何をしに行くのか」「（自分に）何が出来るのか」について、
もう少し具体的なものが見えてこないと（思いつかないと）どうにもならない印象。
少しは調べてみようか。


ということで、後期の英語の勉強は、
そのような「現状行く理由と目的もないけど使えて損はないでしょ」という
ネガティブな理由によりポジティブに行動しています。
国内にいて英語で困ることがないレベルならそれでいいかなーという気もする。
でもそれって立場による気が。

あとは色々開発したいアプリも増えたので、
そっちを作るのにすこし時間を割く必要もあるなーと。
MIDIシーケンサーもどきとかモーション生成VSTプラグインとかDirectXでトゥーンシェードとか。
ちまちま設計中。

当面の方針としては、来年どこかにインターンしに行く予定（審査とか通れば）。 Googleでグラフィカルな事とかできないもんですかね。検索データの可視化みたいな。
（結局そういう方向に行く。。。）
ちなみにこのブログは一応、検索避けを施されている模様（そう設定した）。

StreamCloudミーティング記録9/27

定例ミーティングまとめ。＋雑記。

今後の方針としては2通りで、
・処理系スクラッチ実装（Java）
・SystemSで実装
の二択。

前者はブラックボックスがほぼ無くなる＋実クラウド環境で実験可能。
だが高コスト＋時間無い＋お金がかかる（当然）。
後者は工数少なめ＋実験に時間を割ける。
でもブラックボックス（地雷？）多数＋実クラウド環境利用不能。

結論としてはまずSystemSでの実装の方向で。
スクラッチの方が（今後のスキル強化を考えれば）多少魅力的だが、
今このタイミングでそのリスクを負う必要もないだろうと判断。

水曜までに最適化問題ソルバの調査と、
SystemSコンポーネント図のアップデートを行う。
最適化問題ソルバのコンポーネントなどが追加されるため。

//---------------------------------------------------
まぁ困ったらUDOP使えば、ほぼC++なんだし、
もう少し気合でどうにかしてみよう。
最近気合の預金残高が底をついてるのに目を瞑ればですがね！
（院試諸々で使い切った模様）

StreamCloud今後

ゼミの宿題終わり（半ば強引に）。
今後はアプリケーションによる実験に向けて、
作業工程を切り出す。あと関連論文読み。

切り出した作業工程と、残り時間とカレンダーを見比べながら、
どのあたりに落し込むか検討することにしよう。

研究室ゼミ第一回

私の番終了（宿題付き）。

次週に、実験の部分の説明のし直しと、新しい定式化のドラフト。
//--------------------------------------------

しかし、ドキュメントを作るのが遅くてがっくり。
その上間に合ってない。むむむ。

書くのが遅い←次に何を書くか分かってない←全体の構造を把握できてない←理解が足りない←英語が読めてない←…以下略…

どこまで遡るかはともかく、せめて全体の構造くらいは
把握できるようにしておきたいですね。
人の話のメモを取るとか（例えば次回のゼミとかで）、
リアルタイムで構造化して出力する訓練が必要。

先天的にできないのなら訓練を施すしかないので分り易い構図。

論文読み夏の陣（気温的に）

しばらく論文読み作業。
前回（ICDE勉強会）の経験（苦渋）を活かして、計画的にコツコツ読んでいこう。
とりあえず今週中に１本精読。
残りの９本はまず概要を読んで、その上で優先度の高い２、３本を
並行してじっくり読み始められれば理想的（現状では）。


今後的には、１日１本くらい読めてようやく話になるかならないか、ですが、
理想と現実にはギャップがつきものですね。

蛇足ですが日曜日は先約が入っていまして、
ちょいとBerlitzの方に行ってきます。主にお金の話。
なるべくお安くしたいですがね……。

一定の学習効果を確保しつつ、費用を最小限にする最適化問題。
ストリーム私。

どこがストリームだっちゃ（英語の読み過ぎで若干深夜テンション）。

CEDECレポ 蛇足

下の記事ですが、何故か表示がうまくいってません。
エディタが悪さしてるようです。長すぎたからでしょうか。。。

CEDECでパンフレットと一緒に、
これまた何故かマクドナルドのコーヒーのタダ券を頂きました。
結構あるので、学生室のテーブル上に置いておきます。
適当に消費してください。

行ってないセッションの記事があったのでついでにペタリ。
（適宜追加かも）
http://www.gamebusiness.jp/article.php?id=2077

CEDECレポ

8/31～9/2の間、
CEDEC　http://cedec.cesa.or.jp/2010/
に参加してきました。ゲーム開発者のカンファレンス。

私が受講したセッションの中で、
研究室に多少関係がありそうな部分について紹介＋レポ。
（おそらくこの後、CEDEC運営が大体のセッションの資料を公開すると思います。
それは後ほど。今回は簡易レポ、という形で。）

• メニーコア時代へのプログラミング言語からのアプローチ
  （インテル株式会社）

コンシューマハードも複数コアの時代になり、

CPUのクロック周波数も今後そこまで上昇しないことを受けて、

開発側も並列化に対応しなければならない。

並列化の手法としては、

・SIMD（命令レベルの並列化）

・マルチスレッド（ロジックレベルの並列化）

の2つの並列化がある。

SIMDについては、ハンドアセンブリが一番単純な方法だが、

CPUが新しくなったときに、新機能が使えないという問題が残る。

そこで、コンパイラ側で自動ベクトル化を施せば、CPUに応じた機能を用いて

並列化ができる。インテルが色々と開発中。

あと、SIMDのビット幅を512にしたり1024にしたりすればもっと並列化が出来るね、とも。

マルチスレッドについては、Win32スレッド、OpenMPなどがあるが、
ここでは"Intel Cilk"（OpenMPに近い）を紹介（宣伝）。
まとめとしては、このあたりの機能を将来Intelがサポートしますよ、という感じ。

• ネットワークゲームの仕組みとゲームデザイン
  （株式会社セガ） 

ネットワークゲームの仕組みについて紹介。

ゲームの方式として、「完全同期式」「非同期式」の二種類がある。
完全同期式は、複数ユーザーが同じ時に、同じゲームの状態を必ず共有している、という方式。
格闘ゲーム、RTS（Real Time Strategy）などがこれに該当。

非同期式は、ユーザーによってゲームの状態が（問題ない範囲で）多少異なる方式。
FPS（First Person Shooting）、MMO（Massively Multiplayer Online）RPGなどが該当。


通信方式は、TCP、UDP、ReliableUDP（パケットロスのないUDP）などがあり、


ゲームハードの通信機能に応じて利用する（NintendoDSの場合、WifiならTCP、ワイヤレス通信ならUDP系、といった感じ）


当然、帯域の制限があるので、送信する情報量を無尽蔵に大きくするわけにはいかない。

ゲームの種類によっては送信する情報量は大きくないものもあるが、

FPSなどの非同期式では、プレイヤーのステータス（位置情報、体力、その他ゲーム中の状態を示すパラーメタ）をすべて送信する必要があるものもある。
その場合、差分転送を用いることで、（1秒間に60回画面を更新する（通信する）なら、前後のパラメータの中で変わっていないものはそれなりに存在する）情報量を抑えるなどの対策を施す。
この辺は研究室の輪講でも出てきた話に近い。（気象関係のセンサーデータの送信時に差分転送を用いるとか）

• メニーコア対応ゲームエンジン

昨今のメニーコア化、および今後のそれを受けて、どうゲームエンジンを作るか、という話。
全体的に抽象的な話。

並列化に際して、メモリ転送の部分がボトルネックになってくる。
この辺はゲームの方でも同じらしい。
細かいことは資料が出たら、ということで（メモ不足＋把握しきれず）

• 
  
  

  コーエーの作品における、大量のキャラクターを同時に表示・制御する手法「シングルスレッドからマルチスレッドへ」
  （株式会社コーエー）

ゲーム中に、画面中（カメラの範囲内）に大量のキャラクターが表示される状況になると、当然描画のために処理時間がかかるので、FPS（1秒間の画面更新の回数）の低下が起きる。
アクションゲームである以上、FPSの低下は避けたいので、どのようにして高負荷を抑えるか、という話。単語を置き換えるとStreamCloudの主旨に近い気がする。

セッション中では、単純に処理を減らすための対策手法と、マルチスレッド化による最適化について言及。
対策手法については、描画が重くなるタイミングというのはゲームの状態からある程度予想がつくので、それらの検知を行い、キャラクタなどの描画の質（LoD: Level of Detail）を下げることで負荷分散を行う。

マルチスレッド化については、各処理に依存関係があると並列化が難しくなるので、依存関係を減らすことが重要。1フレーム前の状態を参照するとか、処理を細分化して並列化するとか。

• 
  
  

  ソーシャルゲーム×クラウド：米国最新事情
  （Amazon Web Services）

クラウド環境を利用したソーシャルゲーム（基本的にブラウザアプリケーション。毎フレームごとに画面を更新するタイプのゲームは少なくとも多数派ではない模様）の現状を紹介＋AWSの宣伝。
計算リソースを外部化できるので、ゲームの開発に集中できますよ、という主旨。

東京のデータセンターと、日本のサポートチームを現在立ち上げ中？とのこと。

//---------------------------------------

全体的に（研究室と無関係のセッションも含めて）、最近の要素技術、トピックの紹介＋解説が主で、アカデミック的にガツガツしたのは多くなかった印象。
内容的には（当然といえば当然）隣のK研究室の方が近そうでした。
むしろポスターセッションの方がアカデミック的だった様子（見る時間ありませんでしたが）
ちなみに、東工大から熊澤研が出ていた模様です。

学生は30人くらいはすれ違った気がします。全体の5%程度でしょうか。

院試合格しました

私の明日はこっちだ！（→権藤研

……研究室に残れなかったのは、確かに残念なのですが、
これはこれでアリだなあ、、、という予想外の展開に。


ということで、本来はもっとゆっくりやるつもりだったのですが、
残りの時間で、盗める技術と知見とその他諸々はごっそり貰っていきますので、
改めましてよろしくお願いします。（酷い話だ）

しかし人生面白いものです。率直な感想。

院試終わりました

私の明日はどっちだ！！！（以下次号

StreamCloud論文投稿完了

本日、無事StreamCloudの論文をIC2010に投稿しました。
鈴村先生、研究室の皆様、様々なご協力どうもありがとうございました。
これから院試までは、停電期間もありますし、
自宅で院試勉強をする予定です。

今回の論文については、半ば切り上げる形で
論文化したので、これからの部分がかなり残ってます。
その辺は院試後に詰めていければ、と。

院試の勉強はおよそ順調です（認識が間違ってなければ）。
やればやるほど運任せ感が漂う出題傾向に心が削られますが、
それもあと2週間も無いので、大人しく机に向かうことにしましょう。

めも

http://suzumura-lab.blogspot.com/2010/07/streamcloud.html
 あとで（8/17～）読む

近況報告

ひたすらに院試の勉強中。StreamCloudのドキュメント書きも並列して続行中。
勉強がもう少し進んだら実装とかも進めたいが、
それなりのリスクが伴うので最近は消極的。

腱鞘炎になると色々と困るので、適度に手を休めながら字を書く。
筆圧が強い方らしいのでこういう時に面倒。
今季は授業をとってないので、長時間字を書く習慣が殆ど無かったし。

しかし休んでる間にキーボードをカチャカチャってそれはどうなのか。。。

ドラフトは大体書き終えたので、夜にもう一度目を通して先生に提出予定。

Export/Import 2

レイテンシ計測機能追加。
しかし最大30秒弱のレイテンシが発生している模様。
前にもこんなことがあった気がしたが、
このレイテンシが正しいならノード稼働の遅延の原因はこれか。

Exportのソースを読んでみたところ、
bufferなるオブジェクトがあるようなので、
この辺に溜まっている可能性があるのか？

もう少し調べる必要がありそう。

STCP/CTCP

Source()["stcp://hogehost:port/"]{}　などの記述、、、
スラッシュは2つですよ！

コンパイル通るけど3つ書いちゃダメですよ！！！


コンパイラ仕事して下さい。。。

Spade

正しく書いたはずのFunctorが何故か動いていない。
こういう時は多分先入観が原因。

明日monitor*.shを使って確認するのがベターか。

//----------------------------------------

電気回路は少し時間が要りそう。
通信理論、論理回路はやってみると面白い。
複素関数論はこれはこれで。

とりあえずさっさと18～22年までの過去問片付けよう。

院試勉強スタート

院試勉強始めました。（冷やし中華的に）
研究は夕方～夜、または勉強中の思考実験の末にまとめてばばっとやる方針。

CPU使用率をノード増減の基準にするのは、
ネットワークインテンシブだと主張するのに矛盾してるような。
松浦さんと同じようにレイテンシを測ったほうが良さそう。

いずれにせよ、稼働状況を通知する機構をノード側に組み込んで、
それを集計してコアに送る機構を今週中に作る予定。
これができて、雁瀬さんのモジュールを連動させた後にEucalyptusと連動させれば、
実験環境の大枠はできたことになるはず。

uCosminexus Stream Data Platform

http://gihyo.jp/dev/serial/01/sysinfra/0005
uCosminexus Stream Data Platform
日立版　SystemS　みたいな？


http://www.hitachi.co.jp/Prod/comp/soft1/cosminexus/products/lineup/application/sdp/academic.html
教育・研究目的での貸し出しも行ってるとか。

私の観測範囲で偶然見つけたのでメモメモ。

IOボトルネック

いろいろ試してみたところ、
結局、ノード側のSinkの部分の書き出し部分がボトルネックになって、
結果的に全体の流速が落ちているのではないか？との考えに至る。

明日、余計な出力を全て塞いで試してみる。

実験2

初期ノード2、20秒ごとにノード数1追加の実験結果。
前回より、約80秒後に新ノードにタプルが到着するのが分かっているので、
大体予想通りの結果か。
60秒前後のスループットの増大は原因不明。気になる。

60秒過ぎてからのスループットが本来のスペックなのだとすれば、
ノード数増加に合わせてスループットは下がっているので、
いい感じに負荷分散がされているようだが果たして…。

で、次はノードを減らしてみるテスト。
初期ノード4、20秒ごとにノードを1つずつ減らしていく。
ここでも80秒ルールが明らかに見て取れる。

順当にスループットは上がっているので、
（エラく綺麗に1/4→1/3→1/2→1/1とスケールしてますね）
CPU的には余裕の模様。
そりゃあタプルのカウントしかしてないしね。
要するにボトルネック解消しろってことですねコレは。
どこにSplitを仕込むかは明日相談かな…まぁ大体見当つくけども。

Export/Import

Export/Importは、どちらの順でプログラムを立ち上げても繋がるのを確認。
これでクラウド上のVMに後からプログラムを走らせても、
正しくExportを拾ってきてくれるはず。


で、簡易の実験結果。

 

2秒ごとに、到着したタプルの合計を計算して吐き出すだけのお手軽アプリ。
実験開始から20秒時点で、使用ノードを1台増やしたのだが、
実際にノード2にタプルが到着したのはそれから80秒後。

テスト段階からこの手の動作は観測されていました。

考えられるのは、ノードの追加をした瞬間、
既に「80秒分のタプル」は最初のノードの方に
割り振られてしまっているのではないか、ということ。

要するに1ノードではボトルネック、ということ？
逆に考えると、ボトルネックが発生している状態では、
ノード追加の指示を出してから反映されるまでのオーバーヘッドが
増大傾向にあるのではないか？と予想。

まぁ実装がミスってなければ、ですけども。
他のパターンとかでも実験する必要がありそう。

というか今日、投稿多すぎですね。
見づらいかもしれませんがすみません。

JoinOp.

Joinオペレータの入力タプルに初期値を与える方法は無いものか。

input1＜count(0)＞ ; input2＜count(1)＞
のように定義すると、input1に新しいタプルが来るたびに、
その時の最新のinput2のタプルの値が適用されて出力タプルとなるが、

input2に「最初の」タプルが来ない間はどうしようもないので、
input1のタプルはすべて捨てられてしまう。

で、現状の実装では、このinput2の入力はTCP通信に依存しているので、
コネクションが貼られて、向こうからデータが来るまでの間、
input1の入力（こちらはファイルからロード）は捨てられている模様。

うまい回避方法がなかなか見つからない。
「最初の方の一部（しかも可変長）削られますよ」ってのはどうなのかなー。

ノード側プログラムのSPLIT

SPADEプログラムのファイル名を、一々プログラム毎に変える必要があったので、まとめて make, make clean, submitjob, canceljob を行う split.sh を作成。
今後似たような状況が発生した場合に役に立つかもしれません。

/nfs/home/ishii/spade/streamCloud/　の中。

メイクファイルいじり

ノード用SPADEをID毎にコピーしないで、
コマンドライン引数に抽出して楽をする作戦敢行中。

しかしこれが、
「SPADEファイルとアプリケーション名が一致してなければいけない」
条件に阻まれ難航中。
何故にファイル名まで同期取る必要があるのか分からない。

面倒くさいんでファイル名を一々変更するように仕込むか…。
ちょいと納得いかないですねー。


追記。
メイクファイルにシェルスクリプトを埋め込んでみたものの上手くいかない。
大人しく.sh書くか…。

StreamCloud 実装開始

SPADEのアーキテクチャはこんな感じ。（先生との議論＋独断のまとめ）

えいやっとSPADEをガリガリ書いて実装。動作を確認。
意外と書けるもんだ。
これで基盤部分はおおよそ完成。
きちんと動作したので、一部の冗長な部分をリファクタリングしたあと、

実験の準備に移る。

順序としては、先に時間によって動作ノード数の変更を通知する
サーバープログラムを用意して、ノードの増減が正しく動作するのを確認してから、
実験用のプログラムに内部をチューニングする。

それとクラウドマネージャ的なサーバーとの連携、
実際のEucalyptusインスタンスとの連携、
（物理マシンもVMも同じ扱いなので、そこまで手間ではない）
各ノードの稼働状況をモニタするサーバーの用意、etc、、、も後ほど。


そこはかとなくオーバーヘッドがある気がしますが、
まだ気がするだけ。本当なら実験データにでも現れるでしょう…。


来週中にこの辺りまで終わらせられると、
論文化の道に光が見えてくるようなそうでないような。
コツコツ詰めていきましょうか。

NEC中央研見学＋α

NEC中央研究所の見学に行ってきました。
データマイニングRGの藤巻さんに色々とお話を伺うことができて、
進路決めにあたっての情報が結構増えました。

博士に進むかどうかは、やはり慎重に考える必要がある、
というのを今回改めて確認。

結局のところ、人生のコンセプトといいますか何と言うか、
何処に自分の情熱なり信念なりを置くのか、という問題に
終始するような気がするのですが、
私の場合はその置所が微妙な位置になる気がするので、
（それが許される立場かどうかも含めて）
色んな人に話を訊きながら見極める必要があるなーと思います。

多分シンプルな解としては、
一般的な東工大生的（？）に、普通に（また微妙な表現だ）
就職すればいいんだと思います。それが一番無理がない。
ただそれだとあまり面白くないので、
無理のない範囲で、どこまで色を付けれられるか、
という問題に落ち着くのでしょうか。
面倒な性分に育ってしまったものです。これも自己責任。

それと、相変わらず言葉遣いがなってないので、
（敬語は赤点スレスレとしても、もう少し簡潔にはっきり喋れと小一時間以下略）
今後も意識しないと何時まで経っても直らないので自戒。

他の企業の研究所とかの情報も
就活もどきよろしく少しずつ収集しておく。メモメモ。

//------------------------------------------

上野さんとC++談義（途中から上野さんのJSONパース講座）を延々繰り広げ、
テンプレート（メタ）プログラミングを勉強する熱が湧いてきました。
色々欲しい本も溜まってきたので、
明日まとめて生協に注文かけようそうしましょう。

//------------------------------------------


英語。。。
GABAとBerlitzの資料請求を今朝したら、
早速日中にカウンセリングの電話案内が掛かってきてちとげんなり。
（サイレントモードにしていたので全部スルーでしたが）
基本的に電話とかメールとか、好きじゃない性分なので、
余り不必要に鳴らして欲しくないですね。

おそらく明日明後日には届くと思われますので、
興味のある方は、必要でしたら適宜研究室に持ってきます。
お金の問題は、ある程度は片付きつつある感じです。
でも結構高いですねこりゃ。

論文読み

カレンダーはこまめにチェックしましょう。いやホント。

それはさておき、
ここ数日はICDEの論文読みに集中した方が良さそう。
論文のつまみ食いはともかく、精読には全く慣れてないので、
良い薬になると予想。

クラウドマネージャ的なスクリプト

TCP通信でコマンドを受け取って、
VMの立ち上げ、停止の命令を出すサーバスクリプトを実装開始。
とりあえずVMの代わりにディレクトリの生成消去の動作を確認。

インスタンスID、鍵などは.conf的なファイルからロードしておけばよし。

やっぱりコード弄っている方がテンション上がりますね。
表情が変わらないのは仕様です。

Sink→シェルスクリプト→インスタンス起動

SystemS内のジョブスケジューラが、クラウド上のインスタンスの起動を命じる場合、


・適当なファイルをSinkする　
・↑をシェルスクリプト側で待ち受ける（ファイルサイズ等でチェック）
・インスタンス起動（Euca2ool等がそのまま使える）


の構成だと、SOAPなどのAPIを直接使わず実装可能、だと思う。
APIを直接触るなら、
http://getcloudfusion.com/
などのEC2のライブラリを使うと良さそう。ただし、主要機能以外だとEucalyptusには対応していない場合があるので注意。

微妙に変わったので訂正。詳細は後ほど。

インスタンスの調整

アチラを立てればコチラが立たず的な状況が相次ぎ泥沼中。
とりあえずISOからイメージを作る手段は、
やってみる価値があるので、一旦仕切りなおしてそちらに進む。

しかし工数の見積り・次の一手の決定が上手くできないのが一番痛い。
バックグラウンドがあるフィールドじゃないので、
当然と言われても文句は言えないが、
見通し無しの暗中模索はそれだけで神経が削られる。

最悪手を引く事になったとしても、さほど抵抗はない。
自分が明るくない方面の知識系統も、ある程度入りましたし。
まずは出来ることを一つずつ詰める。

英語のネットラジオについて＠仙台

簡易調べものまとめ。
http://success-english.net/internetradio_news.htm
英語のニュース系ラジオのストリーミング配信は、探せば結構あるみたいです。

今、WNYC（米、NY近辺）のを聴いてみてますが、リスニングの勉強にはなるはず。
（内容的にどうなのかは、そこまで判ってないので何とも…）

私個人としては、アメリカ英語を一番聴いておいたほうが良さそうなので、米国内のを中心に探してますが、
人によってはブリティッシュだったり、その他（イスラエル英語？）だったりするかもなので、その辺は適宜。

JSONのパースなどについて＠仙台

仙台は涼しいです。
こんな時期にこっちにいるのも上京して以来なので3、4年ぶりですが。
運転免許更新とパスポート申請などは、何事も無く終わりそうです。
日曜の夕方頃に東京に戻ってくる予定です。

SystemS＋UDOPでJSONの解析　をするのは、ちょいと前に調べたので雑記をば。

• 参考
  http://www.json.org/json-ja.html

JSONデータの中に改行コード等が含まれるTwitterの投稿データなどは、
正規表現を使うにしても抜け漏れが出たりして今一つ信用が置けない。

かといって見ての通り、JSONをパースするとなると、
ちょっとしたコンパイラ的なコードを書く必要があって若干面倒。
で、C++で使えそうなライブラリを探してみましたが、

• Boost:PropertyTree
  http://www.boost.org/doc/libs/1_41_0/doc/html/property_tree.html

このあたりが恐らく使えるのかなーと考えてます。

（JSON文字列）→[UDOP: JSONParserForTwitter]→（必要な属性（本文、投稿時間、ユーザー名など）のタプル）

こんな感じでJSONをパースして必要なものだけ取り出すUDOPを一つ作っておけば、
（どれを取り出すかは各自チューンする、そもそもTwitter.com側でJSONの内容が追加・変更されうるので、一度作ればずっと使えるかは怪しい）
後はUDOPを複数用意して並列化すれば、ある程度高速化できるのではないでしょうか。

後ほど時間作って老木さんのコードも見てみよう。

インスタンス起動・ログイン成功

ついにこの日がやってきました。
Eucalyptusの導入を始めて幾星霜（≒一月＋α）。ええ、長かったです。
CC側で（手動で）起動したDHCPデーモンがようやく噛み合ったらしく、
正しいIPアドレスを割り当ててくれました。
ただし、STATICモードとして指定したIPとは別のIPアドレスを割り当てたので、
※（DHCP設定のIP割り当て範囲）＞（STATICモードの設定の割り当て範囲）
STATICモードとして正常に機能しているかは怪しいです。むしろSYSTEMモード的？
ここらへんも追々調べる必要があります。

まだ確認事項はそれなりに残っていますが、
何にせよ、ようやくここまで辿り着きました。ばんざいばんざい。

/* もう少しでコアラが嫌いになるところでした */

//-----------------------------------------------------

最近自宅で、院試の勉強に必要な教科書やノートのサルベージ中。
この際、理論系の知識の再構築を徹底的にやってしまうのも手か。
実際問題、院試でこの研究室に残れないと色々笑えない。
（でなきゃ、私は何のために奥村研究室etcの内薦を目前に「筆答試験を受けます」と即答したのか）

国際経験も確かに必要だけれど、
今の私では負荷が大きすぎるし（…まさか体調まで崩すとは、自分でも呆れ気味）、
「院試を確実にパスする」方が最優先事項なので、
もう少し段階を踏む方向にシフトチェンジしよう。
ようやくEucalyptusの方が、進展の兆しを見せ始めたので、
こちらもここからが本番といえばそう。前期の間に、可能なら論文化したいし。


多少の損は承知の上で安全運転。

STATICモードで奮闘中

エラーメッセージは余りログに吐かれなくなってきたが、
（インスタンスが正常に立ち上がらない系統のそれらを除けば）

いかんせん上手くいかない。
Eucalyptus側でDHCPサーバーが動作していない様で、
これではこちらが指定したIPアドレスも割り当てられるはずもない。

このあたりをもう少し調査する必要がありそう。

それと、インスタンスの立ち上がる時間が20～30分近くかかるのも問題。
原因はEucalyptus側が、インスタンスの立ち上げ、終了に応じて、
一々VMイメージをコピー、削除しているのが原因。
キャッシュしておけるのかどうかは現在不明。
Web上の記事と比較しても遅すぎるので、こちらのネットワーク環境の問題の可能性もある。

インストールに引っかかってからかれこれ一月。
色々勉強にはなっているものの、そろそろ突破できないといい加減苦しい。
「できないことを覚えながらやる」のが前提なので当然といえば当然だが、めげる。

あと、StreamWeb発表＠フロリダの件も、
手続き関連に尽く引っかかってこちらもグッタリ。
無理してでも行った方がいいのか、
もう今回は旗色が悪いのか（院試も受ける必要が出たし）
自分でも良く分からなくなってきた。

先生が帰ってきてから一旦状況を整理する必要がありそう。
情けなしも致し方なし。

インスタンスが立った

ようやく。
ただしまだログインできない…
（起動時にフリーズしている模様。Xenからコンソールでログインすると、初回のみ起動中のログっぽい表示がダンプされる）。

とりあえず、Eucalyptusが使うDHCPサーバーの設定を適切にする必要がある。
ログインできない問題については、VMイメージの問題か？
あるいはlibvirtかXenの問題。とりあえず、Xenで起動するイメージを、st00からコピーしてきてXen単独で起動するかチェックする必要はありそう。

VMイメージ再登録

一部マシンイメージの設定が怪しかったので再登録。
しかしまだPendingのまま。

おそらくネットワークのブリッジ部分の設定が悪いようなので、後で直す。

立て、立つんだ、インスタンス

イメージの登録は滞りなくできた模様。
意気揚々とインスタンスを立ち上げるも、状態が"pending"から"running"に変わらないまま。

/var/log/eucalyptus/nc.log を見てみると、
libvirt: cannot read directory /etc/xen: Permission denied (code=38)
libvirt: Domain not found: xenUnifiedDomainLookupByName (code=42)
とのメッセージが延々表示される。

昨日残っていたlibvirtがらみのエラーが悪さをしているらしい。

ちょいと調べてみたら、本家のドキュメントにて、

• On some distros (CentOS), if you are using Eucalyptus with Xen, you might see an error like, [EUCAERROR ] libvirt: cannot read directory /etc/xen: Permission denied (code=38)

This does not affect the node and can be ignored.

……無視ですかそうですか。

となると問題なのはcode=42の方で。

……これを書いている間に気づいたけれども、
インスタンス起動の操作をしているノードがCLC側なのが問題なのか？
そろそろ時間がなくなってきたので明日再考しよう。

Eucalyptusインストール完了？

気を取り直してインストール作業続行。
ログファイルを読み直してみると、（nc側にlibvirt絡みのエラーが見えたが、致命的かは不明）致命的なエラーは無い模様。ノード（se00）、クラスタもクラウドコントローラー側から認識されている。

これでイメージの登録に移って良さそうなので、後日やってみよう。
VMインスタンスを立ち上げる(＋ログインする)ところまで出来れば、
とりあえずはマイルストーンになるはず。

状況整理

先日無事？4～5月の進捗報告が終わりました。
とりあえずStreamTwitterの方は開発環境が整ったのでよし。

次の一月はStreamCloudの方に重点をおいて取り組む予定。
今度は、詰まったらさっさとメーリングリストに投げる方針にしようと思います。
騒がしくなると思いますが、予めすみません。

今日は、一旦Eucalyptus用のマシンの構成などを再確認して、
現在までに得た情報を整理してみようと思います。

蛇足：
昨日の進捗報告の途中で「Google日本語入力がアホ」という発言をしましたが、
誤解の無いように注釈をば。
私が「アホ」という形容をする場合は、
「ちょっと足りないところがあるけども可愛げがある」というような意味です。
殊更、貶めるとか悪く言うとかの意図はありません。

Javaが少し好きになりました

慣れれば結構便利。
本命はいつもC++ですが。

TwitterのStreamingAPIが時々途絶える件、
Pythonのライブラリ側の問題だった様子。
（※人様のを使ってるくせに酷い…）

Javaに切り替えてみたところ止まらなくなった上に高速化。
稼働しだした仮設リアルタイムビューワーの測定によると、
約60Tweet/sec程スピードが出ています。
1時間で22万弱のポストを拾える計算。

本家の流速を500T/s弱と仮定すると、およそ10％強。
gardenhoseの取得率は通常の3倍～5倍と諸説あるようで、
それにJava側でのオーバーヘッドを加味すると妥当なところか。

現在、SystemSに渡す前の時点でJSONデコードを挟んでいるので、
その処理が終わらないと次のTweetを取得できない（はず）。
（取得しそこねたTweetは流されるはず。ゲームのフレームスキップと同じ（例えが悪い））

取得側でJSONをそのままSystemSに投げて、Tweetを分散、
各UDOP内でJSONパースをすれば（要Boostのインストール）もう少し早くなりそう。

マルチスレッド化するとか上手いことして、
取得側のJavaをさらに高速化すれば100T/sに近づけるかもしれない。

20:00頃までビューワーのデコレーションをして、
明日はEucalyptusの続き。それを適当に切り上げて資料作成。第一部完。



初回特有の問題だが、
このひと月は開発環境を稼働させるのに殆どが費やされたのが地味に痛い。
Eucalyptusの方はまだ終わっていないし。
そもそもこちらはそれ自体が勉強なので何ともな部分もあるけど。

StreamTwitterが軌道に乗れば、
StreamCloudの方にまとまった時間を割けるので、
このまま軌道に乗ってくれればいいけれど。日々是精進。



追記。
ビューワーをマルチスレッド化したら80t/sまで高速化。やったー。

インストールがまだ終わらない

Eucalyptusのインストールに中々トドメを刺せない。困り物。
rpmのインストールまでは上手く行っている気がするのだが、
ノードの登録が上手く出来ていない様子。
（ノード追加コマンドを叩いても、そ知らぬ顔）

バージョンを1.6.1に下げてみるのも手だが、
それで解決するかは分からないし、ごちゃごちゃになるのも御免被りたいし、どうしたものか。

GW過ぎて、大分煮詰まって焦げ付き始めた感。
めげずに日々是精進。

やや振り出しに戻る

Eucalyptusの設定が中々キマらないので、
version1.5.2にダウングレードしようかと企んだが、
CentOS5.4に対応したのはver1.6.*だけという事実。

日本ユーザー会のwikiは現在、1.5.2までしか翻訳されていない。
結局、本家のドキュメント（英語）を読むのが一番早そうという結論に。

2週間前からそうしてれば良かったといえばそうですが、致し方なし。これも勉強。



それと、Twitterモニタは、AS3.0だとセキュリティによって、
通信部分が制限（解除はできるが、面倒＋難＋よく分からん）されているので、
一旦Java+ProcessingでJavaアプリとして作成。
可能であれば、後々アプレットにする。

3歩進んで5歩下がった感じだが、これも勉強。

OSSベースのクラウドコンピューティング最前線

第6回JEUG（Japan Eucalyptus Users Group）勉強会、
"OSSベースのクラウドコンピューティング最前線"に参加してきました。
会場は日本IBM本社。ちょっとだけ社会見学。

案の定（？）どう見ても学生なのは私だけでした。
ちょっと大人になった気分です。

セミナー順に雑感をば。

• 13:40～14:00
  「日本ユーカリプタスユーザーズグループの紹介と活動方針について」
  JEUG共同発起人　前彿雅人　氏
•  JEUGは現在メーリングリスト登録数150人規模の団体。初心者ウェルカム。
  メーリングリストに登録してみるのもいいかもしれない。
  Wikiのドキュメントのバージョンは現在1.5.2だが、最新バージョンの1.6.2についても鋭意翻訳中とのこと。

• 14:00～15:00
  「Eucalyptusの紹介」
  JEUG　肝付兼続　氏　
• 初心者向けのEucalyptusの紹介。今まで調べた知識の復習に最適だった。
  およそ間違っていなかったので安心。
  現在のEucalyptusの機能は、EC2と比べるとまだ不十分というのが大勢の見解の模様。ver_2.0に期待が持たれるとのこと。

• 14:50～15:10
  「Eucalyptusの検証結果の報告とプライベートクラウド構築サービスの紹介」
  クリエーションライン株式会社　代表取締役　安田忠弘 　氏
• 主に会社の紹介。東大院と連携して"yass"というHadoopみたいな？ファイル分散システムを作ってる（た？）とか。
  残りは子供には難しい話だったので割愛。

• 15:10～15:30
  「Eucalyptus」をベースとしたクラウド基盤としての「ClassCat Cloud」とGAE（Google App Engine）互換の「ClassCat WebApp Engine」の紹介
  株式会社クラスキャット　代表取締役　佐々木規行　氏
• こちらも主に会社の紹介。子供には難し（略

• 15:40～16:40
  IBMクラウド事例から考えるOSSによる企業向けクラウドの可能性
  日本IBM　Linux/OSSエバンジェリスト　中井悦司　氏
• IBMのクラウドの取り組み事例（もとい宣伝？）と、Eucalyptusのキックスタートの実機デモ。
  CLC-CCはスクリプトで半自動化、NCについてもネットワークブートで、空のノードを自動的にNCインストール済みにしてしまうというスグレモノ。
  Eucalyptusに何処まで深入りするかは未定だが、後々キックスタートを作れるなら諸々の作業が楽になるかも。
  あと"IBM Linux"でググると情報ソース的に良いことがあるとか。

後でググるメモ。
セミナー中で出てきて気になった単語。重要度はまちまち。

• Elastic Load Balancer
• ElasticFox
• HybridFox
• CloudBerry S3 Explorer
• Lucie EC2 //←松岡研？
• RightScale
• yass

それと、5/12～14に、有明で「第1回クラウドコンピューティングEXPO」があるとか。
時間がある時に調査。

それとIBMの中井さんの話の中で、
「OSSではユーザーインターフェースの拡充がされてないものが多く、それが周知、導入の敷居を上げている」的な事が挙げられてました。
バイト先でもUIの部分を開発してますし、そもそも趣味が趣味なので、頭の片隅に置いておくことにしましょう。
どこかで役に立てることがあるかも。

Flash開発関連あれこれ

MITライセンスでWindows専用のFLASH、ActionScript2.0/3.0等の統合開発環境。

• 本家
  http://www.flashdevelop.org/wikidocs/index.php?title=Main_Page
• 日本語コミュニティ
  http://flashdevelop.jp/%E3%83%A1%E3%82%A4%E3%83%B3%E3%83%9A%E3%83%BC%E3%82%B8 

最近日本語化がされたようで、導入はかなり楽。
Adobe FlashCS3/CS4互換らしいので、私の場合は自宅のCS3と連動可能らしい。

StreamTwitter以外でも、
ちょっとWebインターフェースを作成するのにいいかもしれません。
以上宣伝。


続いて便利そうなもの一覧。

• Frocessing
  Javaの描画ライブラリ、ProcessingのActionScript3.0移植版。
  完全移植というよりはクローンらしい。ライセンスはLGPL。
  http://www.libspark.org/wiki/nutsu/Frocessing

• Papervision3D
  ActionScript3.0での3D処理ライブラリでは最も有名（？）
  ライセンスはMITライセンス。
  http://code.google.com/p/papervision3d/

併用は難しいかもしれないけども。
（OpenGLとDirectXを同時に使おうとする感覚？）

3DをPapervisionで済ませて、その上に貼り付けるスプライトを
Frocessingで書ければ理想的。たぶん。

GUI側の構成は、
Updateプロセスがひたすらタプルを受け取って内部モデルを更新、
Drawingプロセスが指定されたFPS値に基づいて、定期的に内部モデルを参照して
描画を行う構成にする予定。

明日のバイトのあとに、Papervisionのテストをやってしまいたい。
それとActionScript3.0でのソケット通信の実装。VIVAコード書き。

System S連動開始

とりあえずSystem SとTCPでつないで、
発言内容をSinkさせるとこまでは完了。
次は発言内容以外の、なるべく全部のデータを乗せて、
総Post数遷移、その他諸々の統計情報を解析するUDOPを書く作業に移る。
それとSink出力をTCPに変更して、FLASHによるGUIへ枝を張る準備もしないと。

StreamCloudの方の、export-importのテストもしたいので、
この辺の実装作業を進めることで、実装コストを下げる。



5000行～10000行の開発に耐えられるコーディング的な意味での体力は、
最近ようやく付いてきたようですが、
（バイト先で書いたC#も、通算10000行弱にはなってきた模様）
言語仕様方面の知識が追いついてないので、
きっとスマートに書けていない気がするのが最近の悩みのタネ。
特にC++とか。

大学を出るまでに、C++とJavaについてはそれなりのスキルと知識を身につけておきたいが、
Javaで書くプログラムの当てが件のDSMSくらいしか無いのが何とも。
ゲーム屋的なバイアスの所為か、Javaの使いどころが中々見つからない…。
（DirecｔX関係弄るならC/C++だし、GUI作るならC#使うし…）
単にWindowsユーザーなだけか？
何にせよ、VS2010導入に合わせて、C++0x、テンプレートメタプログラミングの知識をさらって、
C++関係の各書（古典、最近の両方）を読む時間を作りたい所。

時間があったら（多分無い）Lispにも手を出してみようそうしよう。

日本人ユーザーのあぶり出し

飛んでくるJSONデータをパースして、
言語設定が日本語になっているユーザーの絞り込みに成功。

（ちなみに私のHN用のアカウントは言語設定が英語なので、こういう偏屈野郎は拾えないのに注意。）

この方法の良いところは、日本人ユーザーが「日本語でない言語」でPostした時も拾えること。
英語とか、ローマ字表記とか。

コンソールに垂れ流すのが明日デモれるはず。

APIから飛んでくるタプルの内容

後々仕様が変わらないとも限らないので何とも言えないが、とりあえず列挙。

• text //Post本文
• in_reply_to_user_id //リプライ宛のユーザーID
• coordinates //経緯度？
• geo //？
• created_at //投稿時間
• contributes //？
• source //投稿元（Web、クライアント、APIなど）
• in_reply_to_status_id //リプライ宛のPostのID
• place //？
• truncated //？
• in_reply_to_screen_name //リプライ宛のユーザーの名前？（ユーザーIDではなくて）
• user //ユーザー情報の構造体の模様。
• favorites_count　//お気に入りの数
• profile_text_color　//テキストの色
• time_zone　//タイムゾーン
• created_at　//twitter開始日？
• statuses_count　//Post総数
• notifications　//？
• profile_link_color　//リンクの表示色
• description　//？
• lang　//言語
• profile_background_image_url　//背景画像のURL
• profile_image_url　//アイコンURL
• location　//Profile欄の所在地
• contributors_enabled　//？
• following　//フォロー
• geo_enabled　//上の"geo"が有効かどうか
• profile_sidebar_fill_color　//サイドバーの塗りつぶし色
• profile_background_tile　//背景画像をタイリングするかどうか
• screen_name　//名前（notユーザーID）
• profile_sidebar_border_color　//サイドバーのボーダーの色
• followers_count　//フォロワーの総数
• protected　//鍵付きかどうか
• verified　//公認（公式？）アカウントかどうか
• url　//プロフィール欄のURL
• name　//ユーザー名
• firends_count　//？相互フォローの総数？
• id　//ユーザーID。内部的に用いられているインデックスと思われる。
• utc_offset　//UTC補正値。タイムゾーンから分かりそうなものだが。
• profile_background_color　//背景色。画像を使わないときに適応される（はず）
• id　//PostのID
• favorited　//お気に入りに入れられたかどうか？

おそらくuserのlangの属性を見れば、ほとんどの日本人ユーザーが抽出出来そう。
発言textに日本語が含まれるかの結果とマージすればおそらくほぼ全体になるだろう。


（上の条件を「常に」くぐり抜けるユーザーは、英語表示など、日本語の表示を設定せず、また日本語によるPostを行わないユーザーである。）

ストリーミングAPI開通

今朝からpythonをちょこちょこ弄っていたら、
ようやくTwitterのStreaming APIにアクセスできました。
といってもtweepyというTwitterAPIバインド使用ですが。使えるものは使うのですよ。

とりあえずコンソールにダラダラ垂れ流し。思いのほか流速は早め？

あとはコイツをTCPで垂れ流してSystemSにつなげてもいいし、ログファイルに書き出してもよし。

パッと見、日本語のPostは多め。最低でも2割、最高（最悪？）4割？
……日本は素敵な国です。駄目な方の意味が7割。

netem

今日のディスカッションでsa05がCLC-CCノードになった訳だが、
偶然にも（？）sa05にはnetemはインストール済みだった。ラッキー。

早速レイテンシのエミュレートを実験。

tc qdisc add dev eth0 root netem delay 200ms
このコマンドで、Ethernet0に200msの遅延を挟ませる。
実際にst00からpingしたところ、見事に200msの遅延が確認されました。
（→返り値の time=200ms）
ちなみに元が0.2ms程度なので、ほぼ指定した値通りになります。

tc qdisc del dev eth0 root
これで遅延解除。
細かい使い方は必要に応じて後ほど。

これで、研究室内で、日本国内～アメリカ西海岸の通信のエミュレーションが可能に。
sa05へのEucalyptus CLC-CCのインストール、st00へのEucalyptus NCのインストールは完了したので、あとはEucalyptusとネットワークの設定と格闘するだけ。
この手の実装はどうやっているのか気になるといえば気になりますが、
下手に首突っ込んでも泥沼になるだけな気がするので気になるだけに。

実験測定インストールに明け暮れてコーディングがあまり出来ない日々。
やっぱりコード書いてる時が一番楽しいですね。

Amazon EC2 のレイテンシ [調査]

更新に間が空いてしまいました。
調査系タスクなのでGoogle先生にお願いして、ばばっと。

http://d.hatena.ne.jp/rx7/20091203/p1
こちらによると、東京からの通信によるレイテンシは、

• us-east（アメリカ東海岸:　ヴァージニア）: 193～195msec
• us-west（アメリカ西海岸:　カリフォルニア）: 117～121msec
• eu-west（アイルランド）: 283～284msec

の様な感じ。

http://blogs.itmedia.co.jp/kurikiyo/2008/12/post-b95a.html
こちらの記事も参考に。

やはりアメリカのサーバーとの通信には200msec程度のレイテンシはかかる様子。
※記事にもある通り、そもそも光速で通信したとしても、光は１秒間に地球を7周半するとして、地球の裏側と通信するのには0.5/7.5 = 約0.0167sec、片道でこの時間なので、往復では約0.133sec。
つまり物理法則に従っている間は、地球の裏側と通信するにはどう頑張っても100msec以上のレイテンシを覚悟しなければならない、ということ（蛇足）
ということなので、
実際の環境（Amazon EC2を日本国内から使用した場合）をエミュレートする時には、100～200ms程度の遅延を加えてやる必要がある。

netemの遅延コマンド、 # tc qdisc add dev eth0 root netem delay 10ms
があるので、これを使ってみる。CentOS5.4にはプリインストールされていないので自前で入れる。
遅延を掛ける部分はCLC-CC間。Eucalyptus的には、CLC,CCは同じ物理マシンなので、User-CLC間でもいいのだろうか？
Amazon EC2のこのあたりの実装はどうなっているのだろう。




/*
以下余談。
0.133secというと、アクションゲームなどでよく用いられる60FPS（Frame Per Second: 1秒間に60回画面の描画をすること）で換算するとほぼ8フレーム。
レイテンシのレベルとしては、確実に「遅延している」と判断出来るレベル。
（格闘ゲームの世界チャンプで3,4フレームなら反応できる（その間に適切な操作を入力できる）とか聞いた気がしますが実際どうなんでしょ） 

二番目の記事にもあった通り、グラフィカルなWebアプリケーションなどで、頻繁に通信を行う場合は、この遅延は露骨に現われると予想されるので、通信を行うサーバーを何処に置くか（地球上の何箇所に設置するか）というのはかなり重要と思われる。
*/

備忘録

来週のタスク。

• Eucalyptusの設定＋動作確認。
  builderの記事を参考に進めてみる（水曜まで）

• VWAP実験、ネイティブ環境の性能向上の余地について（原因が以下）

• SystemSのPE割り当て不備の原因追求？

• ノード割り当ての仕様確認
• ネットワーク的に死んだと判定されたノードに再度チェックを入れているかどうか
• そのジョブの間にノードを追加できるかどうか

•  Eucalyptusの導入についてのノウハウ解説の準備
• 本家の論文も役に立つはず。ちまちま読む。

この辺りを中心に進めていきませう

はじめてのEucalyptus

ひとまず自分でやってみよう。
参考URL

• http://blog.kirie.net/linux/243.html 
• http://builder.japan.zdnet.com/sp/09-personal-cloud/
• http://oss.infoscience.co.jp/eucalyptus/wiki/EucalyptusConfiguration_v1.5.2/

兎にも角にも本体のダウンロード。
http://open.eucalyptus.com/downloads
ページ中段、"Eucalyptus via packages"より
CentOS-5 RPMs: 64-bit
をダウンロード。

適当なフォルダに解凍。
出てきたフォルダに入って、先に
# cd eucalyptus-1.6.2-rpm-deps-x86_64
# rpm -ivh *.rpm
で、依存するサードパーティアプリのインストール。

その後、生成されたフォルダ（直前のフォルダのひとつ上）で、
# rpm -ivh *.rpm
でインストール。
足りないパッケージがあった場合は、適宜yumでインストール。
（java-sdkとか、libvirtとかが足りなかった。）
再度インストールすれば通るはず。

インストール後、
# chkconfig –list eucalyptus-cloud
# chkconfig –list eucalyptus-cc
# chkconfig –list eucalyptus-nc
がoffだった場合はonする。

ポート開放云々に必要そうだったので、
nmapをインストール。

# /etc/init.d/eucalyptus-cc start
# /etc/init.d/eucalyptus-cloud start
でCLC(Cloud Controller)、CC(Cluster Controller)を起動する。

※ログファイルは、
/var/log/eucalyptus/
設定ファイルは、
/etc/eucalyptus/　にそれぞれ生成される模様。
参考サイトのパスとは違うので注意！

上記が大体終わったら、
適当なブラウザで、
https://マシン名:8443/　にアクセス。
セキュリティ証明書を無視して突撃すれば、Eucalyptusのログイン画面が出てくる。
初期設定は、
Username = admin
Pass= admin
となる。

2010.04.09　とりあえずここまで出来た。

Amazon EC2・マシンの予約について

http://aws.amazon.com/ec2/
Amazon EC2の概要抜粋。
主に課金体系がらみについて。

前提として、
「実際に使用したリソースについてのみ課金対象となる」ようです。
使用したと見なされる条件は、インスタンス立ち上げ、またはデータ転送。

また、マシンの予約はできる模様。
年単位で一時金を支払い、マシンを予約状態にする。
予約したマシンを使用した場合の料金はディスカウントされる。
（通常の４割程度？）
使用しない場合は料金は発生しない。


先日の先生とのディスカッションで出た予約の問題は、（予約の概念があるので）これで解決するかも。
一時金を支払う、という問題は残るが。
 
http://aws.amazon.com/ec2/purchasing-options/
課金についての詳細はこちら。
あとで読むかも。


補足。

・SLA（Service Level Agreement）99.95%
（信頼性。でも何についての？）

Xen起動時間など

boot時間：　約45秒（sshが成功するまでの時間）
save(resume)時間：　約5秒（sshが不能になるまでの時間）
restore（resume復帰）時間：　約10秒（sshが成功するまでの時間）

save, restoreにはチェックポイントファイルというのが必要の模様。

XenとKVMの比較論文読む

http://wiki.xensource.com/xenwiki/Open_Topics_For_Discussion?action=AttachFile&do=get&target=Quantitative+Comparison+of+Xen+and+KVM.pdf
先生に紹介された論文を読んでみる。

意外と1時間くらいで読めた。
最近バイト先で計算幾何学（not計算機科学）の論文と格闘していた所為か。
何にせよいい傾向。

Performance Isolationが今一ピンと来なかったけれども、
外部のリソース消費に対してどの程度影響を受けるか、みたいな感じなのでしょうか。

台数が多いならXen、
台数少なくてIOインテンシブならKVM（の方が速い）、のような主旨。
というよりはアーキテクチャの差を意識しようね、の方が肝要か。

KVMのスケーラビリティなんかは、今後のバージョンアップで改善されるのでしょうか。
（特定の状況下でバグっているようにも受け取れる）

KVMでの実験もする場合は、アーキテクチャの違いを意識した方が
何かとお得（？）かもしれません。

Xen仮想マシンのクローン

一々CentOS5.4のインストールなんか、してられないので。
「設定ファイル、イメージファイルをコピーする」方向でのXen仮想マシンのクローンの方法のまとめ。
余計なことを言うと、
xm clone
とかそういう物はありません。

http://antas.jp/blog/ina/archives/2007/10/xen_domain-u_duplicate.html
基本的にはここを参考に。一部手順を割愛（それで動いた）。

//Xen仮想マシンのクローン方法
※あらかじめ、コピー元の仮想マシンはシャットダウンしておくこと。
面倒くさいのでDomain-0以外は落としておいた方が無難。

・設定ファイル、イメージファイルのコピー
設定ファイルの場所は/etc/xen/
イメージファイルの場所は/var/xen/
※を新マシン名にしてコピー。
イメージファイルはGB単位なので、あまりに多い容量の仮想マシンをコピーする場合は注意！

・ドメイン名、仮想ディスクイメージファイル名、MACアドレス、uuidの書き換え
設定ファイルに書いてあるので、新マシン用に書き換え。場所は上記。
※MACアドレス、uuidは、「最後の一つ前の項目」を1インクリメントしています。
（末尾++は上手くいかなかった）
MACアドレスなら00:16:3e:63:**:e3　←**の部分（ちなみに00:16:3eはXen仮想マシンの意らしいのでいじらない方が良い）
uuidなら 079e8369-f9ad-0e06-0b95-9b360be8ee*a　←*の部分
※ついでにコア数の設定なども調整しておくと良い


・ここまでの設定で仮想マシンを全て立ち上げる。
上手くいかない場合は嫌な予感がします。

このままの設定では、xen console からでしかログイン出来ないので、
IP等の設定も書き換えます。

・xm console でログイン。
・/etc/sysconfig/network　ファイルの、"HOSTNAME"を正しい名前に変更。
・/etc/sysconfig/network-scripts/ifcfg-eth0　ファイル（イーサネットの設定ファイル）を、
コピー元の仮想マシンの設定を見ながら、IPアドレスなどを割り当てる。
※書いていない項目はコピー。必要に応じて正しい名前、アドレスを指定すること。
・バッシュ履歴ファイル　/root/.bash_history　を削除し、その後ログアウトしてxm reboot

//以上クローン方法

この後、nisdomainnameなどの設定を行えば、sshで、通常通り入れます。
こちらでは、vwapの動作が確認できたので、おそらく正常にクローン出来ているはずです。
※ネットワーク的な設定に関しては自信がないので、もし不備がありましたら教えて頂けると助かります。



■3/15 17:00頃追記。
無事xen02～xen05までのクローンが完了。
xen02,03,04は名前通りのコア数。xen05は4コア。
xen04,05はまだnis？に登録されていないので、IP直打ちで入れる。
登録してもらわないとSystemSに認識させられないかな？要調査。

ちなみにIPは、
xen04：～（省略）.144
xen05：～（省略）.145
そのまま連番です。

XenXen気にしないふりしても

VMの仮想CPUの個数の変更について。
Xenの起動設定ファイル
/etc/xen/　
の中に、
cpu="0,1"　//仮想CPU割り当てID
vcpus="2"　//仮想CPUコア数
の記述を追加。もしくは修正。その後でシャットダウン→起動。というかリブート。

xm vcpu-setのコマンドはどういう訳か効いていません…。
最近Xenコマンドの信頼度が目下下落中です。困った。

とりあえずこれでXen01がデュアルコアになった模様。

Xenといっしょ

xen01を新たにCentOS5.4のVMとしてインストール中。
インストール中にxm topで見ると、xen01が立ち上がっているみたい。

ところで、
Xenの仮想マシンを削除する方法は現在公式の手段？はない模様。
ディスクイメージと設定ファイルを削除するしかなさそう。
ディスクイメージの場所は作成時に設定した場所（/var/xen/仮想マシン名）、
設定ファイルはの場所は /etc/xen/仮想マシン名 。
今までのインストール失敗済みVMの残骸が散見されたので、後で殲滅しておこう。

負けないでXen

XenのVM上での実験はとりあえず成功。
コア数[1,4]　×　UDOP数[1,4]　の16通りで実験してグラフにまとめることに。
秒間どの程度処理が出来るのかを拾うのが肝要。

一方で、QuadネイティブでのSystem Sの動作を再度確認。
ここしばらく動作しなかった。原因は先生の仰る通り、仮想ネットワーク系統が見えているせいらしい。
以前に成功したのは一体なんだったのか。

chkconfig --list で起動ソフト（？）の一覧が見れるが、
xend（Xen-Deamonらし）
xendomains
の二つを
chkconfig <上記> off
で起動時に自動で立ち上がるのを無効にした。
（現在も無効なので、Quad起動時にXenは自動で立ち上がらないので注意！）

Xenの起動は、
/etc/init.d/xend start
/etc/init.d/xendomains start
で起動できる。（必ずこの順番！）

終了は、
/etc/init.d/xendomains stop
/etc/init.d/xend stop
逆の順番になるのに注意！
（私にとって身近な例としては、DirecｔXのデバイスの開放と同じ理屈。逆順で停止すること。）

ただし、上記の方法でXenを終了しても、
xm topコマンドが普通に通ったり（Domain-0が生きている？）
System Sが動作しなかったりするので注意。当面はおとなしくrebootすること。
（Xenのフォーラム関係で情報収集するのも手かもしれない。もう少し状況をまとめておこう。）

ともあれ、rebootの手間さえかければ、これでネイティブ環境でも実験ができるはず。
さて何から手をつけようか。

それいけXen

Quadネイティブ上でのSystem Sの動作を確認。
ネイティブ上で行う場合は、XenのVMを停止（電源OFFと同じ状態）する必要がある。
これで実験前の準備は整った…？

Xenの仮想マシンの操作方法。
（ある程度慣れたらまとめて内部ページにドキュメント化します）

・xm create <ドメイン名（インストール時に指定した名前）>
　仮想マシンの立ち上げ。

・xm shutdown <ドメイン名>
　仮想マシンの終了。

・xm top
　稼働中のマシンの状況を表示。

・xm list
　仮想マシンの一覧を表示

・xm rename <ドメイン名> <新しい名前>
　ドメイン名の変更。でもシャットダウンすると元に戻る。

雑感

System Sにしろ脱System S的な何かにしろ、
ノードの稼働状況とか諸々の情報を可視化→出力するツールがあると便利らしい。
そういうのはほとんど私の領分（むしろ趣味）なのでそのうち考えてみよう。

Processingとか、それのAS3.0バインド（？）のfrocessingとか使えば、
面白い感じで表現出来るかも。ただどちらかというとデモ向け。

論文とかの補助ツールなら、グラフのEPS出力とかの方が便利ね。
…個人開発の方もあるし、そろそろPostScript系の勉強もする必要がありそう。

こっそり弄くり回してるDirectX9.0も大分軌道に乗って来た感じ。
3月末くらいには何かしら見れるものが出来そう。

はじめてのXen

・Quad内のXen作業用フォルダ
/var/xen

・Xen徹底入門に従いいろいろテストしてみる。

※QuadにはXenがインストール済みの状態から始めています。
Xenのインストールに付いては他の方、お願いします。

virt-install で、適当に質問に答えながらゲストOSの自動インストールを試みる。
使用したインストールftpパスは以下。
ftp://antaur/CentOS5.2

何回か上手くいかず、強制終了したため、 ゾンビのプロセスが２体ほど出現し、松浦さんに消して貰った後に再度試行したところインストール完了。

仮想マシン名: test
memory: 512MB disk 10GBの構成。



追記の追記。
松浦さんに、仮想マシン上にSystem Sをインストールしてもらいました。ありがとうございます。
仮想マシン単体での、System Sの動作を確認。

QuadネイティブのSystem Sも準備してもらえたので、これで測定の準備は整ったかも。
xmコマンドで、仮想マシンの起動、停止、一時停止など出来るらしいので、 後日そのへんも試してみよう。

Processing

Processing自体のインストールは無事終了（というか解凍するだけですぐ使える優れもの！）。

次にARとの連動。

推奨らしいCaptureDSというライブラリを通した方法は失敗。
どうも今のProcessingのバージョンで色々変わってる？様で、
バージョンが合わない怒られてしまう。

VDIGという別ライブラリ？でやってみたところ成功。
ただこちらは動作が重いらしい。比較できないので実感なし。
ver.1.0.1でないとダメらしいので（1.0.5が最新？）、その点注意。
さらに本家がアクセスできないとかいう状態なので、
ProcessingのBBSから飛んだミラーを拝借。
（多分違法なミラーではない…はず。英語斜め読みなので何ともですが）


これで、Processingでコーディングした結果を、ARToolKitを通して扱えるようになったはず。
Processingの他のサンプルも色々面白そうなので、後で眺めてみる。

これをiPhoneやAndroidにポーティングするとなると色々と骨が折れそう。
それについては後で考えよう。















Android SDK、無事インストール成功。
でもHelloWorldがまだ出来ていない。
どうやら仮想デバイスの生成→連動が上手く行っていない模様。
もう少し資料探して頭冷やせばすんなり解決する気がするので楽観視。

これで、とりあえずのインフラは確保できた、はず。
もう少し動かしてみないとダメですが。

唐突にメモ。

今年もよろしくお願いします。
さて、StreamARスタートに向けてのネットサーフィンまとめ。

iPhone ARKit。iPhoneでARを組み込むとなるとこれを使うのかな？
http://www.moongift.jp/2009/11/iphonearkit/

本家。
http://github.com/zac/iphonearkit/

Android版も出ているとか。
http://github.com/haseman/Android-AR-Kit/

Android開発入門。SDK+Eclipseの模様。
http://www.ibm.com/developerworks/jp/opensource/library/os-android-devel/



奈良先端科学技術大学院大学とワシントン大学HITLのCライブラリ。
http://www.hitl.washington.edu/artoolkit/
紹介記事。
http://kougaku-navi.net/ARToolKit.html#Download



雑感羅列。

iPhone開発:　iPhoneSDK+XCode
Android開発:　AndroidSDK+Eclipse

AndroidSDKにはWindowsが使える。
iPhoneSDKは（当然？）Macが必要。
計算機室以外に自由（計算機室はさほど自由でもないが）に使えるMac端末が無い…ふむ。

auのAndroid携帯は今年頃？春、夏モデルに期待？
http://www.itmedia.co.jp/news/articles/0906/24/news069.html

WindowsマシンにAndroidSDK突っ込んでWebカメラ挿したら
とりあえずな実行環境にならないものか…？
軽く調べた範囲では出来るような気がするけれども。

Webカメラはヨドバシ調べで￥4桁で収まるようなので、
明日新宿に出たついでに眺めてみよう。
比較的安かったらちょっと欲しかったし買ってしまおうか。

「センサーをばら撒く」事を考えれば、
iPhoneもAndroidも両方作ることになるので（セカイカメラのAndroid版も出るらしい）、
ひとまずどちらかの開発環境をローコストで用意することを考える。

2月中旬（おそらく期末試験明け=2/16以降？）に構想発表的な事をすると考えると、
ある程度早いうちに、「何ができるか」については調べておきたい。
「どういうセンサーを作るか」については、いま急いても机上の空論なのでちょっと寝かせる。
「現在どんなアプリがあるか」はアンテナを貼っておこう。

予想される問題「不要な情報が多すぎて邪魔」については、
ユーザーの嗜好に応じて適当にフィルタリング出来るようにする必要がありそう。
どちらかというと私個人が「ノイズ情報大好き」なので、
TwitterでいうPublicTimeLine的な「何でもかんでも表示」は必ず用意したい。


そういえばこのGoogle日本語入力はよく分からないところで変換ミスが起きる。