どうも、はむばねです。
SACSIS行ってきたので自分の行ったセッションについてまとめます。
当日とったメモをもとに書いてるのでｇｄｇｄです。
どっちかっつーと個人的感想の方がまとめになってる部分さえあり。
もうちょっとちゃんと書こうと思ってたはずが、２日経ったら早くも意外と忘れてた。
研究室のwikiにはメモの全文とか質疑応答とか載せましたが、ここでは省略。
まさかいないとは思いますが、必要な方がいらっしゃるならばそれも掲載します。
いつも通り、関係ない人にとってはさっぱり意味ぷーだし、関係者にとってもラフすぎて全く役に立たない感じでいくよー＼(＾o＾)／
なお、本記事に関しては読み飛ばしてもまったく問題ないというかむしろ読み飛ばし推奨です。
/**************/
/*** １日目 ***/
/**************/
○開会の辞
・概略
SACSISのトピックスは以下の３点
-先進的計算システム
-先進的計算システムを支える基盤技術
-実用的基盤システム
今年は
７２件一般応募
４３件採択
２２３名参加
次回は
2009年：広島 5/27-29
・個人的感想
特になし
○グリッドコンピューティングの現状と将来－明日はクラウディなのか？－
・概略
グリッドへの要望は年々高まっており、一般分野でのクラスタ導入の例も現れ始めている。
例えば金融グリッドとしては三菱ＵＦＪ証券が昨年１７９２コア、４４８ブレード導入開始。
創薬グリッドでも、ジョンソン＆ジョンソン、Novartisなどで導入されている。
そしてグリッドの今後として、クラウドコンピューティングという考え方が存在する。
クラウドコンピューティングとは、
-データもプログラムも雲の上に置かれてる
-ネットに接続するブラウザもあれば、どんな端末からでも雲に届く
-一連のIT1機能をサービスとして外部に提供
という考え方。
ようはユーティリティコンピューティングのこと（たぶん）。
クラウドは、スタートアップ企業・時限のプロジェクトにとって強力なインフラとなる。なぜならば、
-初期投資不要
-インフラ管理者・技術者不要
-需要に応じて容量の追加が可能
-スケールメリットを活かし、コスト・価格は下がる
クラウドは先端技術なので、ベンダは差別化競争に注力
つまり、標準化には時期尚早（グリッドの第二世代と似てる）。
ユーザにはスタートアップ企業が多いため、ベンダロックイン回避の優先度は高くない
つまり，標準化への圧力・動機付けが弱い
・個人的感想
グリッド関係のまとめ的なもの．
前半は知っている内容が主だったが，後半は大変勉強になった．
特に，クラウドコンピューティングという言葉は初めて聞いた．
まぁ本文中にもある通り，今まで”ユーティリティコンピューティング”と呼んでたやつの呼び方が変わっただけなんでしょうけれど．
なるほど，確かに今からはじめるところに関しては有用な技術なのかもしれない．
無差別化に向かっているため現在標準化はされていない，というのも納得．
また，質疑応答で出ていたそれ別に標準化されなくてもいいんじゃね？」の議論も興味深い．
○Why Computer Architecture will Now Drive Computer Sience
・概略
無理
・個人的感想
がんばれば聞き取れるっぽいとはいえ，さすがに英語を１時間半，あまつさえ議事録とりながらとか無理ですた．
たぶんシングルプロセッサが限界を迎えた今，並列化でどうにかする流れになってきている．
そうなった時，これから先はシステムスタック，プログラミング言語，チップアーキテクチャもろもろ，全部新しいものが必要となってくるよね，的なお話だと思われる．
/**************/
/*** ２日目 ***/
/**************/
/** セッション：省電力ハードウェア **/
○エネルギー制御を備える自動メモ化プロセッサ
・概略
メモ化とは．
入出力の際，その演算値と演算結果をを保存しておく．
新たな演算の際，過去に使った入力と現在の入力を比較し，それが過去に行われたものと同等のものだった場合演算済みの結果を用いることで演算を省く．
という手法である．
しかし，従来のメモ化手法では平均消費エネルギーが１５％増加してしまう．
理由は，メモ化を行うための機構が電力を消費するから．
そこで，今回はメモ化を行うかどうかを動的に決定することで消費電力を抑える．
具体的には，メモ化のヒット率を随時監視し，ヒット率が低くなるとメモ化を中断する．
また，中断後一定回数関数が呼ばれるとメモ化を再開する．
検証の結果，高速化は少し下がったものの，メモ化を行っても高速化ができなかったプログラムの多くに中断が起こり，低電力化に成功．
高速化がはかれるプログラムに対しては中断が起こらなかった．
平均消費エネルギー１．７％にまで下がった．
再開を行っても５．９％にまで下がる．
結果まとめ
削減サイクル数 消費エネルギー
従来手法 ６．８ ＋１５．４
提案手法 ４．９ ＋１．７
再開含む ６．５ ＋５．９
以下略（間に合わなかった．詳しくは論文参照）
今後の課題として，以下の２点が挙げられる．
-memotblへの登録アルゴリズムの改良
-コンパイラアシストによる登録情報の付加
・個人的感想
去年JSASS(たぶん)で見たやつの発展．
結構いい感じの結果が出ているように見える．
これはハードを使っているわけだが，ソフトウェア的にこういうことはできないんだろうか？
コンパイラの話も出てきてるし，できるなら何かしらのアイデアにはなるのかも？
○MIPS R3000 プロセッサにおける細粒度動的スリープ制御の実装と評価
・概要
背景として，以下の２点が挙げられる．
-システムLSIの高性能化
→消費電力の増大
-プロセスの微細化によってリーク電力が支配的に
→リーク削減が急務
そこで，今回はシステム全体（コンパイラ，ＯＳ，ハード等）の協調による電力消費にチャレンジ．
手法としては，演算単位でスリープを制御，使っていない演算器をスリープさせる．
ただし，スリープモードへの遷移にはコストがかかるため頻繁な切り替えは電力を損失すことになる．
最低でも，Break even Point(BEP)よりも長い間スリープしないと損となる．
プログラムコードから次のWake UP時刻を知りたい
温度によりBEPの変化にも対応したい
そこで，オペコードを拡張（コンパイラとの協調）．
演算後にあえてスリープさせないことが可能とした．
「次またすぐ使うし，電力的に得だよ」ということがわかっていればスリープさせない
CP0内の特殊レジスタでもスリープポリシーを設定可能（OSとの協調）に．
たとえば外気温に応じた制御などが可能．
電力削減効果として，以下の結果が得られた．
演算器だけなら70%のリークを削減
コア全体なら47%の削減
ダイナミック電力はコア全体で平均2.8mW
面積とそのオーバーヘッドは，以下の通り．
PG化に伴う面積オーバーヘッドは41%
DivとMult回路を合わせると全体の４割弱
今後として，以下のようなことが考えられる．
-キャッシュ、TLBの省電力化
-コアはスーパースカラ化、マルチコア化などを検討
・個人的感想
いくつかある演算器のうち，つかってないものは眠らせておけばいいじゃん，という豪快な考えにして細かいお話．
実際，ハードのことなんで何がどのくらいすごくて何がどの程度当たり前なのかはわからんけど，なんとなくすごげ．
実際，なかなかの省電力化に成功している？
○走行時パワーゲーティングのための命令実行制御手法の提案
・概要
背景は，前発表とほぼ同じである．
PGに適したスケジューリングのコンセプトとして，処理が時間的・空間的に集中するよう最適化しなければならない．
つまり処理を行う際にはできるだけ一度に大量の処理を行い，ストール時にはできるだけ長い間ストール．
「めりはり」した実行が必要である．
実行可能でも後回しにすることでリーク電力削減時間を最適化をはかる．
そこで提案手法として，キャッシュミス時のスケジューリング手法を挙げる．
L1キャッシュミスが連続で生じる際の実行の制御，
同時発行命令数の変更手法によるIPCの大小により実行命令幅を調節，などを行う．
複数のキャッシュミスが積み重なりそうな場合はPG全ミスが解決したらPGから復帰という手法をとる．
評価の結果，平均で０．６７％性能低下したが，省電力化に成功．
・個人的感想
先ほどと同じく，リーク電流を削減しようという手法．
今度のは，キャッシュミスが起こった時に回路がアイドルしてたら無駄じゃね？ というわけで，その間スリープさせておく．
でもキャッシュミスのたびに休ませてたら明らか余計に無駄ができるので，キャッシュミスが重なるときだけスリープさせよう，というコンセプト．
最早こっちが感想じゃなくまとめになってきている気もするが，気にしない．
/** セッション：インダストリアル・セッション **/
○仮想化とグリーンIT(AMD)
概要
データセンターにおける電力消費の現状は↓こんな感じ．
バックアップ電源6-13%
サーバ消費電力38-63%
ライト1-2%
エアーコンディショナー空調システム23-54%
Opteron、他との違い
-CPUコアの大幅な改良
1回で128ビットまで演算可能
-キャッシュの大幅な改良
共有のキャッシュを設けることにょってコア間の共有を容易に
-浮動小数点演算の大幅な改良
-最適化された仮想化
実際に使われている場合、機能をフルに使っている場合は少ない
→仮想化
-安定したプラットフォーム
これまでと同じものを流用できる
→サーバのデザインを大きく作り変える必要がない
-電力効率
ワット性能リーダシップ
AMD CoolCore
使われている部分使われていない部分を判断し、使われていない部分にクロック要求を行わない
(例：メモリは使うけどCPUは使わないというパターンは多い→CPU系を切ってメモリ系をフルで)
回路ブロック、回路ごと、などの粒度が可能
リード、ライトなどの切り替えもハードウェアが勝手にやってくれる(PowerNOW!などはOSでやる)
・個人的感想
「あんまり商業色が出ないように」みたいな話で，実際聞いてる時は企業の枠を超えたというか，結構一般的な話もしてくれていた気がするのだが，メモを見るとOpteronの話しか書いていなかった．
仮想化，省電力的に思ったより重要．
昔読んだ「仮想化によってサーバ系マシン全部一つの物理計算機に突っ込む」的な手法も，結構一般的だったのかもしれない．
○三菱UFJ証券におけるGrid Computingの活用例 デリバティブ業務及び研究開発業務への応用(三菱UFJ証券)
・概要
三菱UFJ証券では，"Centuria"という新分散プラットフォームを導入している．
使用目的としては，デリヴァティブ行での利用，研究開発での利用，の二種類．
バッチ・オンデマンド双方に対する性能を追求し，スケーラブルな性能向上を目指す．
可用性の目標としては，MTTR５分/年程度．
デリバティブ業務は，さらにリスク管理部署とディーリング部署に分けられる．
リスク管理業務とは，デリバティブ商品の日次時価・リスク計測．
定期的な処理(日次バッチ)が中心で，毎営業日夜間に行われる．
性能要件としては，規定時間までに完了する必要があるため翌朝までに終わる程度．
ディーリング業務とは，デリバティブ商品のディーリング及びマーケティング．
オンデマンド・リクエストベースの処理が中心で，毎営業日日中に行われる．
複数ユーザからの同時実行も発生する．
性能要件としては，数十秒～数分でのレスポンスが要求される．
研究開発業務もまた，開発・テスト業務と研究開発業務に分けられる．
開発・テスト業務は，デリバティブ業務アプリのテスト用．
日中・夜間問わず不定期に実行される．
性能要件は，特になし．
研究開発業務は，業務の枠にとらわれない，新たな手法の開発や分析などさまざまな目的で利用．
オンデマンドな実行及び更新が可能である．
性能要件は，特になし．
デリバティブ業務>>(超えられない優先度)>>研究開発業務
・個人的感想
Top500にも入り，金融業界では第２位を誇る(らしい)計算能力を持つクラスタの実際の利用方法．
まぁ当たり前っちゃ当たり前のことしか言っていない気もするが，なんとなく聞いてて楽しい．
三菱UFJ証券に入ったらこういうことができるよ！
給料もいいらしいよ！
○最先端テクノロジーと大企業サーバ・アーキテクチャ構築～仮想化・Cell・Cloud Computingを巻き込んだ進化～(IBM)
・概要
Java以外の技術は全部IBMが作ったよ！
WiiもPS3もXBox360も全部IBMだから問題ないよ！
IBMのハードは50年使っても大丈夫！（壊れても自己修復）
一貫性のメーカはもうIBMだけだよ！
次世代アーキテクチャとして、全部やるよ！（次世代の企業基幹サーバはHybrid化する）
ゲームマシン(Cell)作ってたらスパコンに勝っちゃったよ！（ペタフロップスクラス）
zアーキテクチャ作ったら思ったより信頼性高くて画期的だったよ！(Solarisなんて余裕でブッチだよ！)
他の奴らはトップクラスでも富士山の３合目！ IBMは８合目！
・質疑応答
Ｑ．統合化していくと、マーケットが小さくなるのでは？
サーバは安くなります。
時代の流れです。
昔のサーバをしがみついてると売り上げは伸びない（サンの例）。
Ｑ．ハードウェア部門を切り捨てていってる？
安くなってもサーバは作り続ける。
ベースは我々のいいサーバだもの！
そこの収入が減るのは織り込み済み。
あと、そこの製品はIBMは作りません。
IBMで10万以下の製品を作ると失敗するからな！
Ｑ．技術を売るのはいいが、どこで儲ける？
基本路線はたぶん変わらない。
サーバ路線でいく。
Ｑ．クラウドも見方によってはサーバだが、ネットワークとも見れる。その場合、サーバはどこまで？
ネットワークサイドはネットワークに組み込みたがるし、サーバサイドはサーバにネットワークを組み込みたがる。
まぁ、今のところネットワークサイドはサーバ作る技術持ってないだろうけどな！
・個人的感想
一応言っておきますが，このメモはかなり忠実に書いてるよ！
せっかくなので，ここだけ質疑応答も載せておきます（他の発表に関しても，wikiには質疑応答も載せておきます）
「商業色が出ないように」とかの話はどこいったんすかｗｗｗ
東工大の松岡先生が「冒涜された」とブチ切れていたという噂．
確かにえらい発表ではあった．
学生の身分で聞いてる分には、ニラニラできたけど．
とりあえず，弁当うめぇｗｗｗ
○データセンターにおける電力供給システムと省電力化
・概要
データセンターにおいて消費電力は大変な問題．
そこで，データセンターのエネルギー問題を考える組織としてGreen Gridが発足した．
データセンターのリアルタイムデータ収集や，パフォーマンスの評価などを行う．
IT機器が必要とする電力とIT機器を運転するために必要な電力の比PUE．
1に近いほどいいわけだが，2003年の15データセンター（米）の平均PUEは1.95．
2005年の9データセンター（米）の平均PUEは1.63.
改善はされていってる．
一方，データセンター全電力に対するIT機器使用電力の割合DCE．
100%に近いほどよく，0.8～0.9が理想だが，22ヶ所の平均値は49%．
つまり，全電力の約50%が本来のIT機器動作以外に使われている．
以下，データセンターで用いられる機器や直流供給についての話など．
・個人的感想
いろんな意味で体調がマックスにヤバかったので，実は中盤以降ほとんど聞いてない．
これに関してはプレゼンの資料そのものが載ってますので，詳しくはそちらを参照．
どうでもいいけど，Green GridのContributor Membershipの年会費$25,000，General Membershipの年会費$5,000って高くね？
小数点の間違いかと思ったら，普通にコンマだった．
/**************/
/*** ３日目 ***/
/**************/
/** セッション：グリッドと仮想クラスタ **/
○モデルベース資源選択による効率的な仮想クラスタ構築
・概要
グリッド環境上での仮想クラスタの問題点．
各計算資源の性能のばらつきにより，構築時間はもっとも遅い構成制限に依存してしまう．
つまり計算資源をランダムに選択した場合，VC構築に不必要なオーバヘッドが生じる．
提案手法．
大規模ヘテロ環境でVC構築を催促かするノード組み合わせを自動的に決定．
各計算資源のVMセットアップ時間を予測するモデルの生成する．
成果．
既存の仮想クラスタVPCにモデルベースの資源選択機能を拡張．
最大約68%の速度向上が得られた．
VC構築時間のモデリング手法．
VMセットアップを論理的なステップに分類．
ステップごとにモデルを構築．
適切なイメージは既に各ホスティングノードに配備されていると仮定する．
VMセットアップ時間に対する各ステップの割合．
Config:1%制度
Boot:最大30%
Bootステップに関してはモデル精度の向上が望まれる
しかし裏を返せば，70%以上は0.9以上の高い精度
評価と考察．
異なるVMイメージを用いた場合、CPUとDISKの性能が低下したのはなぜか？
2サイト上でVC構築しているため(ボトルネックが発生)
MDOELではSiteBのみで構築
手法のオーバーヘッド．
ハードディスクのベンチマークコスト
モデル値算出のため、あらかじめ計算資源のHDDパフォーマンスを取得する必要あり
ソフトウェア：Bonnie++
資源選択時のソフトウェアオーバーヘッド
今後の課題．
Bootchartをもちいたブートプロセス解析
ジョブ実行時間を最適化する資源スケジューリング
Network-intensive
SPU-bottleneck
実行時における仮想クラスタ再スケジューリング
・個人的感想
CPUスペックなどの値を用いて，計算モデルを立てる．
そのモデルに基づき，あらかじめVM構築にどのくらいの時間がかかるのかの予測を立てておく．
その値に基づき，（現状では）速いやつから選択していくことで最速構築を目指そうという研究．
最短４０秒で構築らしい．
肝心のモデルに関しては，当然写してる余裕なんぞなかったしそもそも写す意味もないと思うので，論文集の方を参照されたし．
上にもあるとおり，70%以上は９割以上の精度を誇っており，見てる限りかなりいい感じに作用しているように見える．
○複数サイトにまたがる仮想クラスタの構築方法
分散する仮想化資源をもとにした大規模アプリケーション実行環境の実現・管理・運用手法として，マルチサイト仮想クラスタを提案する．
単一拠点の計算資源量に束縛されずに構築し，管理コストが拠点数やノード数に依存しないシステムを目指す．
分散拠点に対するソフトウェアのデプロイと管理は面倒なので，単一の仮想クラスタを通して行えると便利．
そこで，多拠点からなる大規模仮想クラスタの構築を！
マルチサイト仮想クラスタ内部に物理クラスタ向けの大規模クラスタ管理システムを導入．
イーサネットVPNにより仮想クラスタ内部ネットワークを結合し，拠点ごとの透過的パッケージキャッシュを実現する．
用いるソフトウェアは，NAPACI Rocks．
-PXEブートインストールによる自動的なノードインストール
-Rollによるクラスタワイドなアプリケーション設定
-cluster-fork、tebtakel等ツールによるクラスタ全体/一部へのコマンド実行
-Ganglia等のモニタプロセスによるノード状態監視
-ノードダウン時の自動復旧
などが可能．
実装はRESTベースAPIで，仮想クラスタ割り当てを行う．
評価．
意図通りの動作はおｋ．
キャッシュにより仮想ノード数の増加に対してもWAn経由トラフィックはほぼ一定．
全ノードの再構築時間は２０分程度であり，物理クラスタに対しても行う場合でも１５－２０分程度の時間がかかることから考えて，有効な数字であるはず．
今後の課題として，仮想クラスタ管理システムなどが挙げられる．
・個人的感想
ここでいう"サイト"とは，（たぶんわかるとは思うけど）ローカルでつながってるのではなくWANで繋がった環境という意味．
実験環境は擬似的（たぶん存在するのは同じ室内）だが，想定環境としては遠隔地同士とかを考えているのだろう．
メモってなかったが，キャッシュがそこそこ重要．
イメージを配布する時に，元イメージが遠隔地にあるからっていちいちWANで通信してたら時間がかかって仕方ない．
そこで，最初のやつがダウンロードし終わったらそこをキャッシュサーバにして,LANでそいつと通信することで早くしようという考え．
上記の構築２０分程度というのは，そのキャッシュの効果．
まぁ，当たり前っちゃ当たり前の考え方．
なんとなく，どのあたりが凄いのがよくわからん気がしないでもない．
○地球観測グリッドにおけるセキュリティ基盤の設計と実装
・概要
時代は，第三の科学（計算科学）から第四の科学(eサイエンス)へ
情報の高度利用に立脚した新しい科学技術研究手法としてネットワークで接続された資源を統合的に活用することが求められる．
その考え方が，Global Earth Observation(GEO) Grid．
グリッド技術，分散環境下，さまざまなデータを使いやすく．
この発表では，セキュリティに焦点を絞ってGEO設計・実装の報告が述べられた．
eサイエンスにおけるVO(Virtual organnization)の考え方．
既存ソフトウェアで少ない開発コストでシステムを実装する．
セキュティへの要件として，複数の組織にまたがる資源への透過的なアクセスの実現，あたかも単一のセキュリティドメインであるようなアクセスを実現する認証・許可機構が求められる．
しかし，自由に参照できないデータが多々存在する．
そこで，データ提供者のポリシに応じた柔軟なアクセス制御を実現する必要がある．
実装としては，GAMAとVOMSを繋ぐ．
考察．
-そもそも秘密鍵は自分で管理が前提。集中管理は許される？
PKIに理解の浅いユーザよりは安全
ユーザの手間が軽減
-証明書の保証レベルを定めてやればいい
IGTFのプロファイル策定
-自前の証明書を利用するユーザには、代理証明書をdelegaionにするのをポータルに組み込んでいる
今後の課題．
-全体アーキテクチャのレビュー
-Tsukuba GAMAの開発
-DB側のアクセス制御
-計算サービスのアクセス制御
-ポリシ記述＆アクセス制御の実現
-実利用を通じたフィードバック・改良
・個人的感想
読んでも意味がわからん概要に意味はあるのだろうか．
ようは，（コミュニティごとに）データが置いてある．
でもいちいちコミュニティごとに違った方法とか複雑な処理をかますのは面倒なので，その辺を全部統合したシステムを作ろう，というのがGEO Gridというもの（だと思う）．
でも，データによっては見せられる人が限られるものもある．
そこで，ユーザ認証などの必要性が生まれる．
コミュニティごとに，ユーザが所属する/しないなんかでアクセス制限を行ったり．
んで，そこの認証管理もシステム側でやってあげようというお話．
技術的にはこれまでのものを組み合わせただけなので，新規性はありません（発表者談）．
なんかセキュリティを前面に押し出すようなタイトルだけど，確かにセキュリティの話をしてるんだけど，なんかこの発表に対して『セキュリティ』というタイトルがつくのはなぜか釈然としないものがないでもない．
/** セッション：広域ネットワーク環境 **/
○glurpy:複雑なグリッド環境で柔軟なプログラミングを実現するフレームワーク
多数の単体ジョブを並列処理のがGridの利用形態である．
しかしGrid上で並列分散計算には，複雑な資源間の協調が必要となる．
グリッド計算上の複雑性として，以下のような点が挙げられる．
-動的参加資源
-資源の故障・脱退
-接続性の問題
そこで既存の既存のアプローチとしては，以下のようなものが存在する．
-バッチスケジューラ
-協調は最小限
-部分的にプログラミング導入
Master-Worker framework
-可能な協調はまだ限定的
最も柔軟なアプローチとして並列処理系，既存言語を分散拡張することが挙げられるが，これはGrid環境の枠組みに当てはまらない
そこで，Grid-ebavled分散オブジェクト指向frameworkを提案する．
環境の複雑さ対応に主眼を置き，簡潔なプログラミングと最小限の設定を実現する．
それがgrid環境用分散オブジェクト指向フレ－ムワークgluepyである．
gluepyでは，以下の問題を解決する．
-スレッドの競合
-イベント処理
-メンバの脱退
gluepyによるプログラミングの特徴として，以下の点が挙げられる．
-Remote Object
-futureを使った非同期RMI
-明示的にスレッドは使わない
-placeholder
-逐次のflowを保ちやすい
・個人的感想
具体的にどういうことをやるのかも書いてあるので，詳しくは論文集参照．
というか，個人的にはプレゼンされてもいまいち伝わらなかった．
なんというか，「ふーん？」という感じ．
そもそもフレームワークとかにあまり興味がないのが原因なのかもしれない．
言語処理系の研究室なのにね．
○ネットワークトポロジを考慮した効率的なバンド幅推定手法
・概要
バンド幅マップを得ることの難しさとして，以下の2点が挙げられる．
-ネットワークの深部の情報が得られない
既存の１対１推定ではボトルンネックリンクしか得られないことがほとんど
-多大な時間と手間を要する
ホスト数Ｎに対して推定すべき組み合わせはO(N^2)
そこで，
-木構造ネットワーク上にバンド幅マップを構築
入力はトポロジ出力はそれの全リンクにバンド幅の値を割り当てたバンド幅マップ
-トポロジは既知とする
-リンクのバンド幅は上下対称とする
という状況に対して，
-正確
ネットワーク深部まで把握できる
-高速
高いスケ－ラビリティ
-ユーザレベルで実行可能
root権限を必要としない
機器や規格に依らない
という目的を満たす手法を提案する．
提案手法．
基本はIperf．
１対１を推定対象の単位とするのではなく，１スイッチ＋３ノードで１セットを推定対象の単位とする．
トポロジを基本セットに分解して考え，それらを葉部からボトムアップ方式で解析していく．
提案週報の特徴．
-詳細なバンド幅マップの推定が可能
基本セット、ストリームの束という考え方を組み合わせることで実現
-高速でスケーラブル
干渉、競合を気にしない
-root権限は不要、ネットワーク機器の設定変更なども不要
実験結果.
11クラスタ,352台．
120秒程度でバンド幅マップが得られた．
推定精度は，プラマイ5%程度．
誤差が出ているのは，同期がずれたりIperfそのものの誤差だと思われる．
推定時間はネットワークの直径に比例するため，O(NlogN)．
今後の課題．
-一般ネットワークの適用
非ツリー
非対称なリンク
ストリームを流す方向も推定して、そこに２本のリンクがあるとして進める，など
・個人的感想
優秀若手研究賞受賞．
たぶん図がないとわかりづらいので，詳しくは論文集を見てください．
優秀若手研究賞ということでなんか色眼鏡が入ってしまってる気はするけど，なんかすごげに見える．
結果も出てるし．
ただ，質疑応答では結構突っ込まれてた．
とりあえず発表が，緊張してるのか落ち着いてるのか，上手いのか下手なのか，ものすごくゆったりしたプレゼンだった．
あとどうでもいいけど，結果で出てくる図がなんかmoso氏が好きそうな感じ．
○プライベートネットワーク内のノードへの透過的アクセスを考慮するTNTシステムの開発
・概要
NAT環境では，中から外への接続は可能だが外から中への接続は（ゲートを除けば）不可能である．
そこでこの研究では，PSAと中継ノードを用いることで透過的なアクセスを可能とした．
今後の課題として，認証の問題が挙げられる．
PSAと中継ノードの接続が切れた場合の対処として，リレーサーバを使用せず直接通信できるような手法を取り入れる．
・個人的感想
トイレに行ってた（というか前の発表の時から行きたかったけど，続き聞きたかったから我慢してた）ので，実は中間聞いてない．
でも，内容的にはたぶんこの概要でだいたい合ってるはず．
特に思うところはない．