このエントリーは Nutanix Xi Frame アドベントカレンダー2018 の12/９分として投稿しています。
Frame エントリー第2回目になります。
前回はFrame で採用されている画面転送方式のお話を書きました。
ザックリまとめると、WebSocket の仕組みでワークロードとクライアント端末（のHTML5 対応Webブラウザ）間の双方向通信を実現しつつ、ワークロード上の画面描写はH.264でエンコーディングして端末へ画面転送するというものでした。
第1回目投稿時には認識していなかったのですが、どうやら私には「誰得検証担当」という使命が課せられていたようで。。
好きなんですけどね、誰得検証。
ただ、本当に誰得なネタを垂れ流し続けても読む価値ナシになってしまいそうなので、価値の有る無しが受け手によって変わるギリギリの線を狙っていきたいと思います。
前回は画面転送方式について説明しました。では今回は実際にどのように接続して、どんな操作感になるのかというところを実際の動画でご覧頂きたいと思います。
とは言え、通常のWindows PC や Mac からだと普通につながってサクサク動いて面白みがないので、本ブログではそれ以外の端末からの接続を試してみたいと思います。
通常のPCからの接続についてはこれでも見ておいてください。（雑
通常Frame にはHTML5 に対応したWeb ブラウザから接続しますが、iOSプラットフォームに対してはクライアントアプリが提供されており、このアプリ経由で接続する事も可能となっています。
今回はこの専用クライアントアプリから接続してみたいと思います。
・App Storeからアプリを入手する
App Store を開き、検索欄に「Frame」と入力したら出て…こない。
下までスクロールしても写真系のアプリばかりが候補にあがり、出て来ません。
Frame クライアントアプリを入手するためには「mainframe2」と入力します。
この「mainframe2」はFrame にリブランドする前の当初のサービス名でした。
この「Frame Terminal」をインストールします。
・Frame Terminal からの接続
早速接続してみます。
Frame Terminal からの接続ではログイン先のサイトURLなどの登録は必要なく、自身のFrameアカウントとして登録しているメールアドレス / パスワードを入力するのみで接続可能になります。
ご覧のとおり、動作はサクサクで非常に快適ですが、iPadのネイティブタッチ操作への対応は正直今一つ。今後のアップデートに期待したいところです。
現状では画面全体をタッチパッドとして利用する仮想タッチパッドモードでの操作が基本となります。
DaaSと言えば、いわゆるシンクライアントの仲間。シンクライアントシステムの特徴の一つに「プアなスペックの端末でも快適に操作できる」というものがあります。しかし、Frameの画面転送は上にも書いたようにH.264エンコードで毎秒数十フレームの画像を送り付ける方式。端末側でその画像ストリームをきちんとデコードしてあげる必要があります。はたしてレガシーなPCはその荷を背負う事ができるのか？
ちなみにFrame のドキュメントサイトにはWebブラウザとネットワークに関するシステム要件は記載されていますが、端末のスペックについては言及がありません。
https://docs.frame.nutanix.com/user-system-requirements.html
今回使用するPCは2005年モデルのThinkPad X41
自治会絡みの仕事でPC-FAXを使う必要があり、ジャンク屋でアナログモデム搭載のこいつを確保した、というのが出会いの理由。
スペックは（初代）PentiumM 1.5Ghz / 1.5GB RAM / Intel 915GM / XGA / Windows XP Pro SP3
ブラウザはChrome のWindows XP 対応版の最終バージョン 49.0.2
結果はこちら
予想通りですがGoogle Earth等の画面変更が激しいアプリは厳しめです。Office やWebブラウザ（動画除く）、メーラー程度ならあまりストレス無く使用できそうです。
ただ、接続中はCPU使用率が高止まりの状況が続くためFANも常時全開運転で精神衛生上よろしくない状態です。
Frame を快適に使うにはもう少し新しい世代の2Core CPU、Core Duoあたりのマシンが現実的と言えるでしょう。（もしくはH.264デコードに対応したGPUを搭載したマシン）
さて、上の検証である程度Frame を快適に使える下限が判明しましたが、こうなればもっと限界を追求してみたいというというのが人の佐賀。
使える使えないは置いといて、実際にはどのあたりの低スペック環境まで接続できるのかというのを試してみました。過去の経験よりH.264をソフトウェアデコードする場合、CPUが500MHzを下回ると無理そうだったので、今回は600MHzのCPUを搭載したこちらのマシンを用意してみました。
工人舎の2in1 PC、 SH6です。
スペックは Intel A100 / 1GB RAM / Intel 945GU / 1024*600 / Windows XP SP3
ブラウザはこちらもChrome のWindows XP 対応版の最終バージョン 49.0.2をインストール。
はたして結果は？？
やはり流石に厳しいというか無理。
画面の書き換えが多くなる操作では体感的には1fpsも出ていません。
CPUも接続しているだけで何も操作をしていないにも関わらず100%付近に張り付いている状態です。実は接続自体も大変に不安定で、仮想デスクトップへの接続も何回かに1回しか成功しませんでしたし、接続できてもパフォーマンス不足で強制切断される事もありました。
恐らく、Frame への接続はこのあたりのスペックが下限という事でしょう。
※誤解無き様に申し上げておきたいのは、端末側にある程度のスペックが要求されるのはFrame だからではなく、H.264ベースの画面転送をおこなう全ての製品・サービスに共通する、という事です。
今回はiPadからの接続および端末スペックの下限を探ってみました。
次回は「その2」としてもう少し違う端末/環境から接続してみたいと思います。
それでは。
Frame エントリー第2回目になります。
前回はFrame で採用されている画面転送方式のお話を書きました。
ザックリまとめると、WebSocket の仕組みでワークロードとクライアント端末（のHTML5 対応Webブラウザ）間の双方向通信を実現しつつ、ワークロード上の画面描写はH.264でエンコーディングして端末へ画面転送するというものでした。
第1回目投稿時には認識していなかったのですが、どうやら私には「誰得検証担当」という使命が課せられていたようで。。
好きなんですけどね、誰得検証。
ただ、本当に誰得なネタを垂れ流し続けても読む価値ナシになってしまいそうなので、価値の有る無しが受け手によって変わるギリギリの線を狙っていきたいと思います。
前回は画面転送方式について説明しました。では今回は実際にどのように接続して、どんな操作感になるのかというところを実際の動画でご覧頂きたいと思います。
とは言え、通常のWindows PC や Mac からだと普通につながってサクサク動いて
通常のPCからの接続についてはこれでも見ておいてください。（雑
iPadからの接続
まずはジャブから。通常Frame にはHTML5 に対応したWeb ブラウザから接続しますが、iOSプラットフォームに対してはクライアントアプリが提供されており、このアプリ経由で接続する事も可能となっています。
今回はこの専用クライアントアプリから接続してみたいと思います。
・App Storeからアプリを入手する
App Store を開き、検索欄に「Frame」と入力したら出て…こない。
 |
| 検索結果に出てこない |
下までスクロールしても写真系のアプリばかりが候補にあがり、出て来ません。
Frame クライアントアプリを入手するためには「mainframe2」と入力します。
 |
| クライアントアプリ「Frame Terminal」がヒットしました。 |
この「mainframe2」はFrame にリブランドする前の当初のサービス名でした。
この「Frame Terminal」をインストールします。
 |
| 右下に「Frame Terminal」がインストールされました。 |
・Frame Terminal からの接続
早速接続してみます。
Frame Terminal からの接続ではログイン先のサイトURLなどの登録は必要なく、自身のFrameアカウントとして登録しているメールアドレス / パスワードを入力するのみで接続可能になります。
ご覧のとおり、動作はサクサクで非常に快適ですが、iPadのネイティブタッチ操作への対応は正直今一つ。今後のアップデートに期待したいところです。
現状では画面全体をタッチパッドとして利用する仮想タッチパッドモードでの操作が基本となります。
レガシーPCからの接続
お次はこれ。DaaSと言えば、いわゆるシンクライアントの仲間。シンクライアントシステムの特徴の一つに「プアなスペックの端末でも快適に操作できる」というものがあります。しかし、Frameの画面転送は上にも書いたようにH.264エンコードで毎秒数十フレームの画像を送り付ける方式。端末側でその画像ストリームをきちんとデコードしてあげる必要があります。はたしてレガシーなPCはその荷を背負う事ができるのか？
ちなみにFrame のドキュメントサイトにはWebブラウザとネットワークに関するシステム要件は記載されていますが、端末のスペックについては言及がありません。
https://docs.frame.nutanix.com/user-system-requirements.html
今回使用するPCは2005年モデルのThinkPad X41
自治会絡みの仕事でPC-FAXを使う必要があり、ジャンク屋でアナログモデム搭載のこいつを確保した、というのが出会いの理由。
スペックは（初代）PentiumM 1.5Ghz / 1.5GB RAM / Intel 915GM / XGA / Windows XP Pro SP3
ブラウザはChrome のWindows XP 対応版の最終バージョン 49.0.2
結果はこちら
予想通りですがGoogle Earth等の画面変更が激しいアプリは厳しめです。Office やWebブラウザ（動画除く）、メーラー程度ならあまりストレス無く使用できそうです。
ただ、接続中はCPU使用率が高止まりの状況が続くためFANも常時全開運転で精神衛生上よろしくない状態です。
Frame を快適に使うにはもう少し新しい世代の2Core CPU、Core Duoあたりのマシンが現実的と言えるでしょう。（もしくはH.264デコードに対応したGPUを搭載したマシン）
番外編： 限界への挑戦
さて、上の検証である程度Frame を快適に使える下限が判明しましたが、こうなればもっと限界を追求してみたいというというのが人の佐賀。
使える使えないは置いといて、実際にはどのあたりの低スペック環境まで接続できるのかというのを試してみました。過去の経験よりH.264をソフトウェアデコードする場合、CPUが500MHzを下回ると無理そうだったので、今回は600MHzのCPUを搭載したこちらのマシンを用意してみました。
工人舎の2in1 PC、 SH6です。
スペックは Intel A100 / 1GB RAM / Intel 945GU / 1024*600 / Windows XP SP3
ブラウザはこちらもChrome のWindows XP 対応版の最終バージョン 49.0.2をインストール。
はたして結果は？？
やはり流石に厳しいというか無理。
画面の書き換えが多くなる操作では体感的には1fpsも出ていません。
CPUも接続しているだけで何も操作をしていないにも関わらず100%付近に張り付いている状態です。実は接続自体も大変に不安定で、仮想デスクトップへの接続も何回かに1回しか成功しませんでしたし、接続できてもパフォーマンス不足で強制切断される事もありました。
恐らく、Frame への接続はこのあたりのスペックが下限という事でしょう。
※誤解無き様に申し上げておきたいのは、端末側にある程度のスペックが要求されるのはFrame だからではなく、H.264ベースの画面転送をおこなう全ての製品・サービスに共通する、という事です。
今回はiPadからの接続および端末スペックの下限を探ってみました。
次回は「その2」としてもう少し違う端末/環境から接続してみたいと思います。
それでは。
コメント
コメントを投稿