--- a/presen/presen.rst	Thu Feb 26 02:05:10 2009 +0900
+++ b/presen/presen.rst	Thu Feb 26 20:46:08 2009 +0900
@@ -1,9 +1,9 @@
 .. include:: s5defs.txt
 .. include:: <mmlalias.txt>
 
-================================================
+====================================================
 分散プログラムにおけるデバッグツールの設計と実装
-================================================
+====================================================
 
 *発表者*
   **小野雅俊**
@@ -12,48 +12,56 @@
   **河野真治**
 
 *所属*
-  **琉球大学 工学部　情報工学科**
+  **琉球大学 工学部　情報工学科　並列信頼研**
 
 
 
-研究の背景と目的
+研究の目的
 ===================
 
-背景
+- 分散アプリケーションの作成時に必要な事
 
-- 分散プログラム作成時にクラスタのネットワーク上の問題を考慮する必要がある。
+  - プログラムの正しさ
+  - スケーラビリティを確保
 
-- 分散プログラム用のデバッグ環境の必要性が増している。
+- スケーラビリティとは
 
-- その上でスケーラビリティを確保しなくてはならない。
+  - ノードの増減に対してアプリケーションの性能が左右されない
 
+.. raw:: html
 
-目的 
+   <center><font color="red" size="big">スケーラブルなデバッグをしたい</font></center>
 
-- Federated Linda上で通常のタプル通信とは別にメタな通信を行うプロトロルエンジンの設計と実装
+Federated Lindaを用いて、Metaな通信を行うProtocol Engineを提案、実装
  
 
-
-発表の流れ
-======================
-
-- Federated Linda
-- Linda API （JAVA）
-- Protocol Engine
-- Meta Protocol Engine
-- Meta Protocol Engineの性能評価
-- 測定
-- まとめと今後の課題
-
-Federated Linda
+Linda
 ===========================
 
 - Linda
 
-  - idで番号されたデータ（タプル）をタプル空間を通してやり取りする。
+  - idで番号されたデータ（タプル）をタプル空間を通してやり取りする。Lindaは非同期で動作する。
+
+.. raw:: html
 
-.. image:: img/7.jpg
+      <table border="1">
+      <tr>
+      <td>in(id)</td>
+      <td>タプル空間からタプルを取り出し、データを残さない。</td>
+      </tr>
+      <tr>
+      <td>rd(id)</td>
+      <td>タプル空間からタプルを取り出し、データを残す。</td>
+      </tr>
+      <tr>
+      <td>out(id,out)</td>
+      <td>タプル空間にタプルを入れる。</td>
+      </tr>
+      </table>
+
+.. image:: img/linda.jpg
    :align: center
+   :width: 400px
 
 
 Federated Linda
@@ -63,35 +71,52 @@
 
   - 複数のタプル空間を相互に接続する
 
-.. image:: img/fedlinda.jpg
+.. image:: img/flinda.jpg
    :align: center
+   :width: 600px
 
 
 Linda API （JAVA）
 ========================
 
-- public PSXLinda open(String host,int port)
+class　FederatedLinda
+
+- PSXLinda open(String host,int port)
 
-  - Linda Serverに対して接続を行う。
+  - Linda Serverに対して接続を行う。返り値はタプルスペースの番号。
 
-- public PSXReply in(int id) 
+class　PSXLinda
+
+- PSXReply in(int id) 
 
   - 指定したIDのタプルの受け取りを要求する。
 
-- public PSXReply out(int id, ByteBuffer data)
+- PSXReply out(int id, ByteBuffer data)
 
-  - 指定したIDにByteBufferのデータを送信する。
+  - 指定したIDにByteBuffer内ののデータを送信する。
 
-- public int sync(long mtimeout) 
+- int sync(long mtimeout) 
 
-  - 接続しているServerとのタプルの送受信を行う。
+  - 接続しているServerとのタプルの送受信のポーリングを行う。
+
 
 Protocol Engine
 =======================
 
-- タプル空間とタプル空間のデータをやり取りする
+- タプル空間とタプル空間のデータをやり取りする。
+
+- 二つのサーバー間を接続するProtocol Engine。
 
-- 前述のAPIを用いた例題
+.. image:: img/uml2.jpg
+   :align: center
+   :width: 600px
+
+Meta Protocol Engine
+================================
+
+デバッグ用の通信は、直接Linda Server内にアクセス出来なければならない。
+
+Meta Protocol Engineでこれを実現する。
 
 .. raw:: html
 
@@ -99,64 +124,20 @@
     <tr>
       <td>
 
-.. class::small
+- 通常のFederated Lindaと同様のin/out APIを持つ。
 
-::
-
-    fdl = FederatedLinda.init();
+- Linda Server内部に直接アクセスする事が出来る。
 
-    getpsx = fdl.open(localhost,10000); 
-    sendpsx = fdl.open(localhost,10001);
-
-    in = getpsx.in(10);
+- 通常の通信とは違うMetaな通信を行う事が出来る。
 
-    data = in.getData(); 
-    sendpsx.out(10,data);
-
-    fdl.sync(); 
+- Linda Server内のメインループで指定する事が出来る。
 
 .. raw:: html
 
       </td>
       <td align="center">
 
-.. image:: img/uml.jpg
-   :width: 360px
-
-.. raw:: html
-
-      </td>
-     </tr>
-   </table>
-
-
-Meta Protocol Engine
-================================
-
-.. raw:: html
-
-  <table>
-    <tr>
-      <td>
-
-- 前述のProtocol Engineではデバッグを行う際に逐次Protocol Engineを用意する必要がある。
-
-- スケーラビリティを確保する為に、Linda Server内に直接Protocol Engineを追加する。
-
-- Meta Protocol Engine
-
-  - Protocol Engineと同じ様にServerに接続する事が出来る。
-
-  - 追加されているサーバー自身にアクセスする事が出来る。
-
-  - 通常の通信とは違うMetaな通信を行う事が出来る。
-
-.. raw:: html
-
-      </td>
-      <td align="center">
-
-.. image:: img/3.jpg
+.. image:: img/meta.jpg
    :align: center
    :width: 360px
 
@@ -166,10 +147,10 @@
      </tr>
    </table>
 
+性能測定
+==============================
 
-Meta Protocol Engineの性能評価
-==============================
-提案、実装したMeta Protocl Engineの性能を評価するため、Ringを用いて評価を行う。
+RingでMeta Protocol Engineの性能を評価する。
 
 .. raw:: html
 
@@ -177,17 +158,13 @@
     <tr>
       <td>
 
-- Ring
-
-  - 通信パケットは一つ。
-  - 通信を行う経路が決まっている。
-  - 分散通信に余り影響を与えない。
+何故Ringか？
 
-- 環境
+- 実装が簡単である。
+- 通信パケットが少ない。
+- 通信を行う経路が決まっている。
+- 分散通信に余り影響を与えない。
 
-  - クラスター、100台
-  - データサイズを1Kb〜1Mb
-  - Torqueを用いた
 
 .. raw:: html
 
@@ -204,59 +181,104 @@
    </table>
 
 
-測定結果
+Meta Protocol Engineの性能評価
+==============================
+
+デバッグ操作等を行うには、全ノードを周回する必要がある。
+
+ノードの数と送る通信パケットのサイズを変更しながら、データが一周及び千週する通信時間を測定する。
+
+動作環境は以下の通り。
+
+- クラスター、最大100台（CoreDuo 2GHz,メモリ1GB）
+
+  - 180台の内安定して使えるクラスタが100台あまりだったため。
+
+- データサイズ 1KB、10KB、100KB、1MB
+
+- Torque
+
+  - 複数人でクラスタを使う際に、ジョブの振り分けを行い他人との干渉を避ける事が出来る。
+
+
+
+測定結果（一周）
 ========================
 
 .. raw:: html
 
-  <center>
   <table>
     <tr>
       <td align="center">
 
 .. image:: img/metaring1.jpg
    :align: center
+   :width: 400px
 
 .. raw:: html
 
-   <p><font size="5">一台あたり 約40ms<br /><br />
-   open/closeの時間が影響</font></p>
+      </td>
+      <td>
+
+- 掛かる時間は台数に応じてLinearに増加している。
+
+- パケットのサイズが変化しても転送速度は違いは見られない。
+
+- 一周のみなので、open/closeなど接続のコストが大きい。
+
+- 実際の通信時間が接続コストに隠れていると考えられる。
+
+.. raw:: html
 
       </td>
+     </tr>
+   </table>
+
+測定結果（千周）
+========================
+
+.. raw:: html
+
+  <table>
+    <tr>
       <td align="center">
 
 .. image:: img/metaring1000.jpg
    :align: center
+   :width: 400px
 
 .. raw:: html
 
-   <p><font size="5">一台あたり 約0.6ms<br />
-   open/closeの影響を受けない<br />
-   デバッグ通信に耐えうる事が出来る</font></p> 
+      </td>
+      <td>
+
+- 接続コストの影響が小さいため、通信のみの時間。
+
+- 1MBのデータを100台で通信した場合の一台あたりの時間は約12ms
+
+- Ringでのデバッグに使用するのに十分な性能を持っている。
+
+
+.. raw:: html
+
       </td>
      </tr>
    </table>
-   </center>
 
 
-まとめ
+まとめと今後の課題
 =========================
 
-- 通常通信に影響を及ぼさない為、スケーラビリティを保持する為
-  Metaな通信を行うMeta Protocol Engineを提案した。
+- まとめ
 
-- デバッグを行う都度にProtocol Engineを用意する事なく
-  Serverが増減しても対応出来る。
-
-- Metaな通信速度からデバッグに使用するのに耐え得る性能を保持している。
+  - デバッグ通信が通常通信に影響を及ぼさない様なMetaな通信を行うMeta Protocol Engineを提案した。
+  - Metaな通信速度からデバッグに使用するのに耐え得る性能を保持している。
 
-
-今後の課題
-=======================
+- 今後の課題
 
-- 同じクラスタ上で別のMeta Protocol Engineが動作している場合、相互に影響を及ぼさないか。
-
-- 実際にMetaなタプルを通信した場合、通常の通信との影響はあるのか。
+  - 同じクラスタ上で別のMeta Protocol Engineが動作している場合、相互に影響を及ぼさないか。
+  - 実際にMetaなタプルを通信した場合、通常の通信との影響はあるのか。
+  - Meta Protocol上でデバッグプロトコルを実際に実装してみる。
 
 終
 ==============