--- a/paper/chapter6.tex	Mon Feb 03 22:14:54 2014 +0900
+++ b/paper/chapter6.tex	Tue Feb 04 03:50:01 2014 +0900
@@ -53,7 +53,7 @@
 \end{lstlisting}
 
 \subsection{Capistrano}
-今回の実験では、48台のサーバ上でCUI版のTreeVNCを立ち上げる必要がある。実験する度に、各サーバに一つ一つにログインしてアプリケーションを立ち上げるのは手間がかかりすぎてしまう。Capistranoを使用することで、この問題を解決することができる。\\
+今回の実験では、48台のサーバ上でCUI版のTreeVNCを立ち上げる必要がある。実験する度に、各サーバにログインしてアプリケーションを立ち上げるのは手間がかかりすぎてしまう。Capistranoを使用することで、この問題を解決することができる。\\
 Capistranoは複数のサーバ上で同時に処理を実行するためのオープンソースなソフトウェアであり、Rubyを用いて作成されている。\\
 
 Capistranoを実行する際に使用するスクリプトをListing\ref{src:capistrano}に示す。\\
@@ -75,9 +75,9 @@
 \end{lstlisting}
 
 \section{木の深さによる遅延}
-TreeVNCは、クライアントを木構造に配置し画像を配信している。\\
+TreeVNCは、クライアントを木構造に配置し画像を配信している。
 木の深さが深くなってしまうと、データが下に届くまでに遅延が発生してしまう可能性がある。
-そこで、木の深さによる遅延がどの程度発生するのかを測定してみた。\\
+そこで、木の深さによる遅延がどの程度発生するのかを測定してみた。
 \subsection{遅延の測定方法}
 RFBプロトコルでは、送られてくるデータの先頭にどのような処理をするかの命令番号が入っている。\\
 表\ref{tb:message}は送られてくるメッセージの一覧である。\\
@@ -97,10 +97,10 @@
 \end{center}
 \end{table}
 
-Listing\ref{src:delay_cli}、Listing\ref{src:delay_serv}は遅延を測るためのプログラムである。
-Root NodeはSystem.currentTimeMillis()を用いて時間を取得し、Nodeへ送信する。\\
-System.currentTimeMillis()は、システムの現在時刻をミリ秒（long型の数値）で取得する関数である。\\
-Nodeはこの値を受け取ると、そのままサーバへ受け取った値を返す。\\
+Listing\ref{src:delay_cli}、Listing\ref{src:delay_serv}は遅延を測るためのプログラムである。\\
+Root NodeはSystem.currentTimeMillis()を用いて時間を取得し、Nodeへ送信する。
+System.currentTimeMillis()は、システムの現在時刻をミリ秒（long型の数値）で取得する関数である。
+Nodeはこの値を受け取ると、そのままサーバへ受け取った値を返す。
 Root Nodeはクライアントからの返信を受け取るとSystem.currentTimeMillis()を取り、差分を出してDelayを求める。
 遅延を測る頻度は、画像を50回送信するごとに1回である。
 \begin{lstlisting}[language=java,frame=lrbt,label=src:delay_cli,caption=遅延を測るプログラム,numbers=left]
@@ -131,13 +131,26 @@
 \end{center}
 \end{table}
 
-並列計算環境のVMは高速なネットワークでつながっているので、遅延が少ない可能性がある。
-そこで、実際にOSの授業で、どの程度の遅延があるのかを測ってみた。\\
-OSの際は25Nodeであったので、段数にすると5段である。
-結果は、164ミリ秒と並列計算環境より良い結果が出た。\\
+\begin{figure}[!htbp]
+\begin{flushleft}
+\includegraphics[scale = 0.8]{images/graph-lost.pdf}
+\end{flushleft}
+\caption{
+  段差(step)によるデータの遅延
+}
+\label{fig:graph-late}
+\end{figure}
 
 
+並列計算環境のVMは高速なネットワークでつながっているので、遅延が少ない可能性がある。
+そこで、実際にOSの授業で、どの程度の遅延があるのかを測定してみた。\\
+OSの授業のときは25Nodeであったので、段数にすると5段である。
+結果は、164ミリ秒と並列計算環境より良い結果が出た。
 
+図\ref{fig:graph-late} は遅延の分布を示したヒストグラムである。X軸は試行の回数で、Y軸は遅延(ミリ秒)を表している。\\
+
+
+\newpage
 \section{画面のフリーズ}
 データがTimeOutによってどの程度損失しているのかを調べてみた。\\
 今回、測定するために画像データのヘッダーの前にシリアルナンバーを付加した(Listing\ref{src:serial})。これによりNode側は、順番通りに画像が来なかった場合、データが損失したことを知ることができる。
@@ -175,9 +188,8 @@
 
 \section{分木の最適化}
 木の分木数が少ないほうが一つ一つのコンピュータにかかるCPU負荷が少なくなる。しかし、分木数を少なくしてしまうと、Nodeが増えたとき、木の深さが深くなり、データの伝搬に遅延が起こる可能性がある。
-上記の実験の結果、木の深さが6のときのデータ伝搬に平均139ミリ秒(0.139秒)の遅延しか起こっていなく、データの欠損も見られなかった。
+上記の実験の結果、木の深さが6のときのデータ伝搬に最遅446ミリ秒(0.446秒)の遅延しか起こっていなく、データの欠損も見られなかった。
 分木数を変更してもコネクションの数はかわらないし、スイッチに対する負荷も変わらない。よって、100人程度で使用する場合は２分木が最適であるということがわかった。
-\newpage
 
 \section{ZRLEとZRLEEのデータ圧縮率の比較}
 作成したTreeVNCでは、従来のVNCで使用されているエンコードを使用しておらず、独自で作成しているZRLEEエンコードを使用している。\\一見ZRLEは辞書が一つでZRLEEは辞書が一つ一つの画像データに付加されていて、データ量はZRLEEのほうが多くなってしまっている可能性があるので、ZRLEEとZRLEのデータ量にどの程度の差が出るのかを調べてみた。