SunRay2で画面描画が遅く残像らしきものが残る Part2

2年ほど前にSunRay2で画面描画が遅く残像らしきものが残るで、SunRayServerをGigaスイッチにつないだ時にクライアント側でチラチラ表示になってしまうという話を書きました。

今回ようやくテスト用のSunRayサーバを構築することができたので、その現象についていろいろ調査してみました。

どうやら、原因はやはりスイッチのフロー制御にあるようです。(フロー制御の詳細は(ネットワーク)スイッチのフロー制御に書いてます)

以下の様なパターンでSunRayクライアントの残像チラチラ現象が発生するかテストしてみました。

テスト方法としてはフルスクリーン表示した画像を次々に切り替えていきました。画面の更新差分が大きいのでこの方法だと比較的残像現象が出やすくなります。

なお、クライアント側の帯域制御は無しにしています。

基本的はフロー制御を有効にしておかないと残像チラチラ現象が発生してしまうようです。

特に、1Gbpsスイッチ間はIN,OUTどちらのポートもフロー制御が必要なようです。

逆に、1Gbpsから100Mbpsに落ちるときは、サーバに近い側のポートさえフロー制御が有効になって入ればいいようです。

スマートL2SWとL3SWを経由したときはDTUが1台あればL3側だけフロー制御を有効にすれば現象は発生しなかったのですが、DTUを2台にすると現象が明らかに発生しました。(DTU1台の時もutcaptureを見ればわずかにパケットロスが発生していました)

このことから、基本的にはSunRay～DTU間のすべてのポートでフロー制御をONにしておくことがわかります。

残像チラチラ現象がひどく発生しているときにutcaptureでパケット損失を見てみると以下のようになっていました。

bash-3.00# ./utcapture -r 00144fe4c025

# TERMINALID TIMESTAMP TOTAL PACKET TOTAL LOSS BYTES SENT PERCENT LOSS LATENCY

00144fe4c025 20121026172544 320379 201124 144734426 63.700 2.701

00144fe4c025 20121026172559 406739 255515 183232052 62.982 3.155

6割程度のパケットロスが発生していますね。

また、この残像現象が発生しているときに、SunRayサーバ側の送信トラフィックを見てみると以下のようになっていました。

bash-3.00# dladm show-dev -s -i 1 e1000g0

ipackets rbytes ierrors opackets obytes oerrors

e1000g0 2114 1999865 0 16804 20144662 0

ipackets rbytes ierrors opackets obytes oerrors

e1000g0 2205 2092329 0 17449 20495296 0

ipackets rbytes ierrors opackets obytes oerrors

e1000g0 1787 1546393 0 17082 20265104 0

ipackets rbytes ierrors opackets obytes oerrors

e1000g0 1952 1742506 0 17198 20203862 0

obytesのところが送信トラフィックですが、20MByte/s = 160Mbpsになっています。

なお、Oracleのドキュメントに、以下の様なことが書いてました。

ネットワークスイッチの中には、サーバー側の接続速度を 1 Gbps に設定すると、Sun Ray クライアントでうまく動作しなくなるものがあります。Sun Ray クライアントは 100 Mbps で実行され、そのデータは X ウィンドウシステムのサーバーから周期的バーストで送信されるため、これらのスイッチでは一定量のデータをバッファリングする必要があります。この状況は、X サーバーからの平均データ速度が 100 Mbps を優に下回る場合でも起こり得ます。

X サーバーは、一定の許容量のデータをチックの間隔で送信するようにプログラムされています。元の実装では毎秒 50 チックありました。X サーバーは、Sun Ray クライアントによって許可された特定の比率で送信できます。

たとえば、Sun Ray クライアントが 40 Mbps の送信速度を許可している場合、X サーバーは、毎秒 5M バイトのバーストで 1/50 秒ごとにデータを送信できます。つまり、サーバーはチックごとに 100K バイトのデータを 1 Gbps の速度で送信できることになります。この速度によって 100K バイト近辺のスイッチにキューのビルドアップが起こることになり、さらにそれによって次の 1/50 秒間にわたってビルドアップしたデータが 100 Mbps の速度でドレインアウトすることになります。

この種の問題を緩和する最初の対策は、毎秒のチック数を毎秒 50 から 100 に増やすことです。上記の例では、X サーバーが 20 ms ごとに 100K バイトではなく、10 ms ごとに 50K バイトのデータを送信することになります。この設定により状況はかなり改善するでしょうが、問題はまだ残るでしょう。毎秒 100 チックの速度が選択されたのは、それが Solaris と Linux ソフトウェアでのタイマーの通常のレゾリューションに対応していたからです。

OSのタイマーを増やすことで、チック数を増やし、それにより状況が改善するという説明です。

Solarisでタイマーを増やすには、以下のようにするようです。

# vi /etc/system

set hires_tick=1　　←追加

再起動

この方法を試してみたんですが、状況は改善しませんでした。

やはり、解決策はサーバ～DTU間のフロー制御を有効にすることと、端末側で帯域制御をかけてやることになるようです。

(ただ、ポート数が多いコアスイッチだとフロー制御が難しい場合もあるようです。あるL2スイッチはフロー制御をOnにすると100MbpsになるとSEに言われました)

Webで調査中に幾つか以下のような参考になりそうなのを見つけたんですが、英語なのでいまいち理解できませんでした。

SR3 DTUs not as fast as SR3+ DTUs ?

** SOLVED ** SRSS 4.2 + OSol 124/125/126 slower thanSRSS 4.1?

[SunRay-Users] Flow Control