考察

6.5.1 QoS 設定プログラムの性能調査に対する考察

QoS

設定プログラムの性能調査では

QoS

情報取得の処理はどちらの

QoS

設定サービス でも同じ処理を行うため同様の時間で返答が返ってきた。QoS設定処理では有線

LAN

で は情報取得と比較して

160 ms

程度の増加とあまり時間の増加がないが、無線

LAN

では 返答までの時間の差が

1

秒以上と大きな差が出た。

これは有線

LAN

の設定ではスイッチに命令を送る通信にシリアル通信を利用するためス イッチに命令を一方的に送るだけで設定が可能なのに対して、無線

LAN

の設定は

Web

イ ンターフェースを利用するため、

HTTP

通信時に

TCP

での相互通信の処理が必要となり、

シリアル通信と比較して処理に時間がかかることが原因だと考えられる。また、

Cube-Lite

と

ThinkpadX32

との差は今回のケースでは最大でも

200 ms

程度と小さく、プログラム の動作が

PC

の処理能力の依存しにくいと考えられる。この結果から、内部で設定変更を 行う処理ならば、非常に短い時間で

QoS

の設定が可能であり、また

QoS

設定用

PC

は処

理能力が高くないものでも処理にかかる時間に大きな変化がなく、Cube-Liteほどの性能 の

PC

でも処理能力に問題がないといえる。

6.5.2 QoS 設定プログラムの負荷の検証に対する考察

無線

LANQoS

設定時は全体的に

CPU

使用率が低く、プログラムの処理が行われてい

る間においても

CPU

使用率が

10

％台前半と非常に低い値を示した。QoS設定時の送受 信データ量は

QoS

設定命令の受信は非常に小さいが、QoS設定処理時は

HTTP

を用いて 無線

LAN

アクセスポイントに

QoS

設定を行うため

QoS

設定命令より大きい値であった。

だが、その場合においても約

17.5 KB/秒 程度と送信されるデータは小さくネットワーク

に対する負荷も非常に低い値を示した。これらのことから、今回使用したアクセスポイン トの

QoS

設定時の設定用

PC

の

CPU、ネットワークの負荷は非常に低く、他の処理やト

ラフィックに与える影響は小さいといえる。

有線

LANQoS

設定時の

CPU

使用率は

QoS

の設定処理を行っている時は

40

〜

70

％と 比較的負荷が高い値を示した。これは

QoS

設定にシリアル通信を用いるため、この通信 を行うために利用したライブラリが

HTTP

の処理をするライブラリに比べて負荷が大き いことに起因すると考えられる。送受信データ量は無線

LANQoS

に比べて設定項目や設 定に対する応答のデータが大きいが、それ以外の

UPnP

の必要な処理の影響からか差は 小さく、送受信データ量に影響が見られなかった。このことから今回作成した

QoS

設定 プログラムは

UPnP

の処理に関しては負荷は非常に低く、低い処理能力でも問題が生じ にくいものであった。実際にこのプログラムの機能がネットワーク機器に搭載される場合 には

UPnP

の処理以外は内部で設定変更を行うだけであり、今回の実験のように外部の ライブラリを利用するケースは少なく、CPUとネットワークに与える負荷は非常に小さ いものになると考えられる。

6.5.3 _{メディア再生時の} QoS 設定時間の検証に対する考察

メディア再生時の

QoS

設定時間では有線

LAN

と無線

LAN

の

UPnP

の処理時間は平均 して

19.6

秒ほどの時間を要した。QoS設定を行わない場合の処理時間との差から

QoS

設 定処理に要した時間は平均で

13.2

秒となった。処理時間のばらつきは大きく、25秒ほど かかってしまう場合から

10

秒程度で終了する場合もあるなど差が出た。今回作成したプ ログラムは

QoS

の設定を行うタイミングでブリッジの

QoS

設定サービスの検索し、発見 後

QoS

設定命令を送る動作を行う。このサービス検索では

UPnP

で

rootdevice

とされる デバイスの検索を行うことで実現される動作のため、複数の

UPnP

デバイスで

UPnP

サー ビスが動作している環境では検索に対するレスポンスが

UPnP

デバイスの数だけ返って くるため、ネットワークのデバイス状況や

UPnP

デバイスの返答の順序が大きく影響し たと考えられる。それ以外に、QoS制御を行わない場合の処理時間もばらつきがあるこ

とから、今回の実験システムでの処理時間のばらつきは

DLNA

の再生処理も起因すると 考えられる。

6.5.4 提案手法を用いた場合の品質改善の検証に対する考察

まず、実験結果で一定の通信速度に安定しないのは、DMRが無線

LAN

で接続されて いることに起因する。これは実験環境の周辺で多くの無線

LAN

機器が使用されているた め、他の機器の通信の影響を受けやすいからである。また

QoS

設定の有無による差が小 さいのは、今回の実験環境ではこのメディア再生以外の通信はほとんど行われてなく、優 先度制御型の

QoS

保証では効果が出にくい環境であったことに起因すると考えられる。

また、実験システムに機器を追加し、他のデバイスで動画の再生を行っている状況で の検証を試みたが、QoSの設定変更を行うと図

6.10

に示すように設定変更のために無線

LAN

アクセスポイントの通信が停止し、その通信の接続が切断されてしまうため検証を 行うことができなかった。使用可能な

DMR、DMP

を用いて同様の検証を行ったところ、

表

6.9

のようになり、再生が継続できない場合が多数を占めた。そのため、この実験シス テムは今回使用した機器では同じデータリンク内で他の通信が行われている状況において 他の通信に影響なく

QoS

の変更をして通信を行うことは難しく、単一のストリームのみ の

QoS

設定が可能なものであった。これらのことから、ネットワーク内で他のストリー ムを検出し、それが使用予定の経路を利用しているかどうかの判別を可能にすることで、

実験システムにおいて提案手法の動作が問題なく行われると考えられる。

表

6.9:

メディア再生時の

QoS

変更による

DMR、DMP

の動作

DMR, DMP QoS

設定変更後の動作

PlayStation3

ファイルサーバから切断され、再生が強制終了される

Windows Media Player 12

バッファ分がなくなると再生が停止し、エラーが発生

Intel AV Renderer

バッファ分がなくなると停止し、再度接続されると再生が継続

DiXiM Digital TV plus

バッファ分がなくなると停止し、再生が終了する

図

6.10:

メディア再生時に

QoS

変更を行った場合

ドキュメント内 JAIST Repository (ページ 60-64)