クラウド ゲーム: インターネット環境が悪い場合の 5 つのクラウド ゲーム サービスのストレス テスト

約XNUMX年前に記事を公開しました 「クラウド ゲーム: 非力な PC でプレイするためのサービスの機能を直接評価する」。 非力な PC でのクラウド ゲームに関するさまざまなサービスの長所と短所を分析しました。 ゲーム中に各サービスをテストし、全体的な印象を共有しました。

この記事や他の同様の記事へのコメントでは、読者がさまざまなゲーム サービスについての感想を共有することがよくありました。 同じことについて反対意見が出ることがよくありました。 すべてが完璧な人もいますが、ラグやフリーズが原因でプレイできない人もいます。 そこで私は、理想的なものからひどいものまで、さまざまな条件下でこれらのサービスの品質を評価することを思いつきました。 ネットワークの品質について話しているのは、ユーザーが常に高速で問題のない通信チャネルを誇ることができるわけではないからです。 一般に、アンダーカットは、ネットワーク運用のさまざまな品質のシミュレーションによるサービスの評価です。

何が問題なのですか？

前述したように、接続として。 より正確には、ゲーム中のパケットの損失です。 損失が大きくなるほど、ゲーマーはより多くの問題を抱え、ゲームに対する満足度が低くなります。 しかし、デバイスに光ファイバーを接続し、アパートの住人全員で共有するのではなく、専用のインターネットを備えた理想的な通信チャネルを持っている人は稀です。

参考までに、接続速度が 25 Mbit/s の場合、1 フレーム/フレームを送信するには 40 ～ 50 個のデータ パケットが必要です。 失われるパケットが増えるほど、画像の品質が低下し、遅延やフリーズが目立ちやすくなります。 特に深刻な場合は、プレイすることが不可能になります。

当然のことながら、クラウド サービス自体は、ユーザーのチャネルの幅や安定性に決して影響を与えることはできません (もちろん、それは素晴らしいことですが)。 しかし、コミュニケーションの問題を平準化するためにさまざまな方法を考えることは可能です。 以下では、どのサービスが問題に最もよく対処できるかを見ていきます。

正確に何を比較しているのでしょうか?

通常の PC (Intel i3-8100、GTX 1060 6 GB、8GB RAM)、GeForce Now (ロシア語版) GFN サーバーはモスクワにあります）、 ラウドプレイ, 渦, プレイキー, スタジア。 Stadia を除くすべてのサービスで、The Witcher のゲームの品質を研究しています。 この記事の執筆時点では Google Stadia にはこのゲームがなかったので、別のゲームである Odyssey をテストする必要がありました。

テスト条件と方法は何ですか?

モスクワからテストします。 プロバイダー - MGTS、料金 500 Mbit/s、ケーブル接続、WiFi ではありません。 サービスのグラフィック品質設定をデフォルトの解像度、つまりフルHDに設定します。

プログラムの使用 不器用な ネットワークの問題、つまりさまざまなタイプやサイズのパケットの損失をシミュレートします。

一律の単一損失。 これは、1 つのパケットのみが失われ、損失がほぼ均等に分散される場合です。 したがって、一律 10% の損失は、100 パケットのうち 10 番目ごとにパケットが失われるが、常に 1 パケットだけが失われることを意味します。 この問題は通常、クライアントからサーバーまでのチャネルに歪み (シールド) がある場合に現れます。

5%、10%、25% の均一な損失をテストします。

不均一な質量損失、ある瞬間に連続して 40 ～ 70 個のパケットが即座に失われる場合。 このような損失は、ユーザーまたはプロバイダーのネットワーク機器 (ルーターなど) に問題がある場合に最もよく発生します。 ユーザーとサーバー間の通信回線上のネットワーク機器のバッファ オーバーフローに関連している可能性があります。 WiFi の壁が厚い場合も、このような損失が発生する可能性があります。 多数のデバイスの存在によるワイヤレス ネットワークの輻輳も、オフィスやアパートの建物でよく見られるもう XNUMX つの理由です。

0,01%、0,1%、0,5%の不均一な損失をテストします。

以下にこれらすべてのケースを分析し、明確にするためにビデオ比較を添付します。 そして、記事の最後には、すべてのサービスとケースからの生の未編集のゲームプレイ ビデオへのリンクを提供します。そこでは、技術情報だけでなく、アーティファクトをより詳細に見ることができます (Stadia を除くすべてのサービスでは、技術データからのデータが表示されます)。コンソールは記録されますが、Stadia ではそのような記録が見つかりませんでした)。

行こう！

以下は 7 つのストレス テストのシナリオとタイムスタンプ付きのビデオです (便宜上、ビデオは同じです。各時点で適切な瞬間から視聴が開始されます)。 投稿の最後には、各サービスのオリジナルビデオがあります。 仲の良い友人がビデオの作成を手伝ってくれました。感謝しています。

シナリオ #1。 理想的な条件。 ネットワーク損失ゼロ

理想的な世界ではすべてがそうあるべきです。 接続の問題はなく、一度の切断も干渉もなく、アクセス ポイントはインターネットのビーコンです。 このような温室条件では、ほぼすべてのテスト参加者が良好な成績を収めました。

パソコン

各シナリオでは、PC ゲームの映像を参考にしました。 ネットワークの品質がまったく影響しないことは明らかで、ゲームは PC 上でローカルに実行されます。 これらのフレームの存在は、「クラウドでのプレイと PC でのプレイに違いはありますか?」という質問に答えます。 理想的な条件下では、私たちの場合、これはほとんどのサービスで感じられません。 以下では PC については何も書きませんが、存在することだけは覚えておいてください。

GeForce Now

すべてが順調で、画像は鮮明で、フリーズもなくプロセスはスムーズに進みます。

渦

ボルテックスは私たちの理想の世界を台無しにしています。 彼はすぐに問題を抱え始めました。写真は他のものよりも悪く、さらに「ブレーキ」がはっきりと見えました。 考えられる問題は、ゲーム サーバーがモスクワから遠く離れた場所にあることに加え、ゲーム サーバーのハードウェアが弱く、フル HD をうまく処理できないことです。 Vortex はすべてのテストでパフォーマンスが悪かった。 Vortex でプレイして良い経験をした人がいたら、コメントに書いて、どこからプレイしたか、そしてすべてがどのようにうまくいったかを共有してください。

プレイキー

ローカル PC と同様に、すべて問題ありません。 フリーズや遅延などの目に見える問題。 いいえ。

ラウドプレイ

サービスは優れた画像を表示し、目に見える問題はありません。

スタジア

Google のゲーム サービスは、ロシア連邦にサーバーがないにもかかわらず、完全に機能しており、一般に、Stadia はロシアでは正式に機能しません。 ただし、すべて問題ありません。 もちろん、ゲーム当時に「The Witcher」がStadiaで利用できなかったのは残念ですが、彼らは「Odyssey」を取り上げました-これも要求が高く、人や動物を切り刻む男についての話でもあります。

シナリオその2。 均一損失 5%

このテストでは、100 パケットのうち、約 20 分の 40 が失われます。 50 つのフレームをレンダリングするには XNUMX ～ XNUMX パケットが必要であることを思い出してください。

GeForce Now

Nvidia のサービスは素晴らしく、問題はありません。 Playkeyのものよりも画像が少しぼやけていますが、The Witcherはまだプレイ可能です。

渦

ここで事態はさらに悪化しました。 理由は完全には明らかではありませんが、おそらく冗長性が提供されていないか、冗長性が最小限に抑えられていることが考えられます。 冗長性は、転送データのノイズ耐性のあるコーディング (FEC - 前方誤り訂正) です。 この技術は、ネットワークの問題によりデータの一部が失われた場合にデータを回復します。 これはさまざまな方法で実装および構成できますが、結果から判断すると、Vortex の作成者はこれに成功しませんでした。 たとえわずかな損失でもプレイすることはできません。 その後のテスト中に、Vortex は単に「死亡」しました。

プレイキー

すべて順調で、理想的な状態と大きな違いはありません。 おそらく、同社のサーバーがテストが実施されたモスクワにあることが助けになっているのだろう。 おそらく、上記の冗長性がより適切に構成されていると思われます。

ラウドプレイ

パケット損失が比較的少なかったにもかかわらず、サービスは突然再生できなくなりました。 何が間違っているのでしょうか? Loudplay は TCP プロトコルで動作すると仮定します。 この場合、荷物の受領確認がなく、他の荷物も送信されない間、システムは配送の確認を待ちます。 したがって、荷物を紛失した場合、配達の確認はできず、新しい荷物は送られず、画像は空白になり、話は終わります。

ただし、UDP を使用する場合、パケットの受信確認は必要ありません。 判断できる限り、Loudplay を除く他のすべてのサービスは UDP プロトコルを使用します。 そうでない場合は、コメントで修正してください。

スタジア

すべてがプレイ可能です。 場合によっては、画像がピクセル化され、応答遅延が最小限に抑えられることがあります。 おそらく、ノイズ耐性のあるコーディングが完全には機能しないため、ストリーム全体が再生可能な場合に小さなアーティファクトが発生する可能性があります。

シナリオその3。 均一損失 10%

10 あたり XNUMX パケットごとに失われます。 これはすでにサービスにとっての課題です。 このような損失に効果的に対処するには、失われたデータを回復および/または再送信するテクノロジーが必要です。

GeForce Now

GeForce では、ビデオ ストリームの品質がわずかに低下しています。 私たちが知る限り、GFN はネットワークの問題を緩和しようと努めて対応しています。 このサービスはビットレート、つまりデータ送信のビット数を削減します。 このようにして、品質が不十分であると思われるネットワークへの負荷を軽減し、安定した接続を維持しようとしています。 安定性についてはまったく疑問の余地はありませんが、ビデオ品質は著しく低下します。 画像に著しいピクセル化が見られます。 そうですね、モデリングではパケットの 10% が継続的に失われることを想定しているため、ビットレートを下げても実際には役に立たず、状況は正常に戻りません。

実際には、画像は一貫して悪いものではなく、浮き上がっている可能性が高くなります。 損失が増加しました - 画像がぼやけました。 損失が減少しました - 画像が通常に戻りました。 もちろん、これはゲーム体験にとって良くありません。

プレイキー

特別な問題はありません。 おそらく、このアルゴリズムはネットワーク上の問題を検出し、損失のレベルを判断し、ビットレートを下げることよりもむしろ冗長性に重点を置いていると考えられます。 10% の均一な損失では、画質は実質的に変化せず、ユーザーがそのような損失に気づく可能性は低いことがわかります。

ラウドプレイ

うまくいっていない、単に始まっていないだけだ。 さらなるテスト中に、状況が繰り返されました。 判断できる限り、このサービスはネットワークの問題にはまったく対応していません。 おそらく TCP プロトコルが原因である可能性があります。 ほんのわずかな損失でもサービスが完全に麻痺してしまいます。 もちろん、実生活ではあまり実用的ではありません。

渦

大きな問題も。 このような状況ではプレイできませんが、画像はまだ表示されており、キャラクターはぎくしゃくしてはいるものの走り続けています。 実装が不十分であったり、冗長性が欠けていたりするのは、すべて同じだと思います。 パケットは失われることが多く、回復できません。 その結果、画質が劣化して再生できないレベルになってしまいます。

スタジア

残念ながら、ここではすべてが悪いです。 流れが途切れているため、画面上のイベントがカクカクと発生し、非常にプレイしにくくなっています。 Vortex の場合と同様、冗長性が最小限であるか、冗長性がないために問題が発生したと考えられます。 「事情に詳しい」数人の友人に相談したところ、Stadia はフレームが完全に組み立てられるのを待っている可能性が高いとのことです。 GFN とは異なり、ビットレートを完全に下げることで状況を救おうとはしていません。 その結果、アーティファクトは発生しませんが、フリーズや遅延が発生します (逆に、GFN はフリーズや遅延が少ないですが、ビットレートが低いため、画像はまったく魅力的ではありません)。

他のサービスも、フレームが完全に組み立てられるのを待たず、不足している部分を古いフレームの破片で置き換えるようです。 これは良い解決策です。ほとんどの場合、ユーザーはキャッチ (30 秒あたり XNUMX フレーム以上の変化) に気づきませんが、アーティファクトが発生する場合があります。

シナリオその4。 均一損失 25%

パケットは XNUMX つおきに失われます。 ますます怖くて面白くなってきました。 一般に、このような「リークな」接続があると、クラウドでの通常のゲームはほとんど不可能になります。 一部の比較参加者は、完璧ではないにせよ、対処しています。

GFN

問題はすでにかなり顕著になっています。 写真はピクセル化されており、ぼやけています。 まだプレイすることはできますが、GFN が最初に提供していたものとはまったく異なります。 そして、それは決して美しいゲームのプレイ方法ではありません。 美しさはもはや評価できません。

プレイキー

ゲームプレイは順調に進んでいます。 画質は少し悪くなりますが、滑らかさはあります。 ちなみに左上は失われたパケットが何個回復したかを示す数字です。 ご覧のとおり、パケットの 96% が復元されています。

ラウドプレイ

始まりませんでした。

渦

非常に強く望んでもプレイできず、フリーズ (画像のフリーズ、新しいフラグメントからのビデオ ストリームの再開) がさらに顕著になります。

スタジア

このサービスは実質的にプレイ不可能です。 理由はすでに上で述べた。 フレームが組み立てられるのを待っている間、冗長性は最小限であり、そのような損失があると十分ではありません。

シナリオ #5。 不均等損失0,01%。

10 パケットごとに、000 ～ 1 パケットが連続して失われます。 つまり、約 40 フレームに 70 フレームが失われます。 これは、ネットワーク デバイスのバッファがいっぱいになり、バッファが解放されるまですべての新しいパケットが単純に破棄 (ドロップ) されるときに発生します。 Loudplay を除くすべての比較対象者は、このような損失をある程度解決しました。

GFN

画質が少し落ちてやや曇っていますが、すべて十分にプレイ可能です。

プレイキー

すべてがとても良いです。 画像は滑らかで、画質は良好です。 問題なくプレイできます。

ラウドプレイ

最初の数秒は絵があり、主人公は走りさえしました。 しかし、サーバーとの接続はすぐに失われてしまいました。 ああ、この TCP プロトコル。 まさに最初の損失でサービスは根幹から崩壊した。

渦

通常の問題が観察されます。 フリーズ、ラグ、それだけです。 このような状況でプレーするのは非常に難しいだろう。

スタジア

プレイ可能。 小さなドローダウンが目立ち、画像がピクセル化することがあります。

シナリオNo.6。 不均等損失 0,1%

10 パケットの場合、連続 000 ～ 10 パケットが 40 回失われます。 70 フレームのうち 10 フレームが失われることがわかります。

すぐに言っておきますが、ほとんどのサービスには顕著な問題があります。 たとえば、画像がピクピクするため、ここでは冗長性は役に立ちません。 つまり、冗長化テクノロジを使用するとプラスの効果はありますが、その効果は小さいということです。

実際のところ、ユーザーのアクションやゲーム自体に対する反応時間は限られており、ビデオ ストリームは継続的である必要があります。 サービスがどのような努力をしても、ストリームを許容可能な品質に復元することは不可能です。

アーチファクトが発生し (パケットの損失を補おうとするため、十分なデータがありません)、画像がぎくしゃくします。

GFN

画像の品質は著しく低下し、ビットレートは明らかに大幅に低下しました。

プレイキー

おそらく、冗長性が適切に構成されていることに加えて、ビットレート アルゴリズムが損失をそれほど高くないとみなし、画像をピクセル化された混乱に変えないため、より適切に対処できます。

ラウドプレイ

始まりませんでした。

渦

始まりましたが、画質がひどいです。 ジャークと沈下は非常に目立ちます。 このような状況でプレーすることはほとんど不可能です。

スタジア

急激な変化がはっきりと確認できます。これは、十分な冗長性がないことを明確に示しています。 画像がフリーズし、その後、他のフレームが表示され、ビデオ ストリームが中断されます。 原則として、強い願望と自虐傾向がある場合はプレイできます。

シナリオNo.7。 不均等損失 0,5%

10 パケットを 000 回繰り返すと、50 ～ 40 パケットが連続して失われます。 70 フレーム中 50 フレームが失われます。

「一律めちゃくちゃ」クラスの状況。 ルーターが火花を散らし、ISP がダウンし、ワイヤーがネズミに噛まれても、それでもクラウドでプレイしたいと考えています。 どのサービスを選択すればよいでしょうか?

GFN

ビットレートが大幅に低下しているため、不可能ではないにしても、再生するのはすでに非常に困難です。 フレームが失われ、通常の写真の代わりに「石鹸」が表示されます。 フレームは復元されません - 復元するための十分な情報がありません。 GFN が回復を提供する場合。 このサービスがビットレートで状況を救おうと積極的に試みていることから、冗長性を活用する姿勢に疑問が生じます。

プレイキー

フレームの歪みがあり、画像がピクピクと動きます。つまり、個々のフレームの要素が繰り返されます。 「壊れた」フレームの大部分は、以前のフレームの破片から復元されたことがわかります。 つまり、新しいフレームには古いフレームの一部が含まれています。 しかし、画像は多かれ少なかれ鮮明です。 コントロールすることはできますが、戦いなどのダイナミックなシーンでは、良い反応が必要になるため、難しいです。

ラウドプレイ

始まりませんでした。

渦

始まりましたが、始めないほうがいいです - プレイできません。

スタジア

このような状態ではサービスをご利用いただけません。 理由は、フレームが組み立てられるまで待つ必要があることと、冗長性が低いことです。

誰が勝ちましたか？

もちろん評価は主観的なものです。 コメントで議論することもできます。 もちろん、最初の場所はローカル PC です。 クラウド サービスはネットワーク品質に非常に敏感であり、現実世界ではその品質が非常に不安定であるからこそ、自分のゲーミング PC が他の追随を許さないのです。 しかし、何らかの理由でそれが存在しない場合は、評価を見てください。

1. ローカル PC。 期待される。
2. プレイキー
3. GeForce Now
4. Google Stadia
5. 渦
6. ラウドプレイ

結論として、ネットワーク問題に対する耐性という点で、クラウド ゲームにおいて何が重要な役割を果たしているかをもう一度思い出させてください。

• どのようなネットワーク プロトコルが使用されているか。 ビデオ ストリームの送信には UDP を使用するのが最善です。 確かなことはわかりませんが、Loudplay は TCP を使用していると思われます。 しかし、あなたはテスト結果を見ました。
• 耐ノイズコーディングは実装されていますか? (FEC - 前方誤り訂正、冗長性とも呼ばれます)。 パケット損失を調整する方法も重要です。 これまで見てきたように、画像の品質は実装に大きく依存します。
• ビットレート適応の構成方法。 サービスが主にビットレートを使用して状況を保存する場合、これは画像に大きな影響を与えます。 成功の鍵は、ビットレートの操作と冗長性の間の微妙なバランスです。
• 後処理の設定方法。 問題が発生した場合、フレームはリセット、復元、または古いフレームの断片で再組み立てされます。
• サーバーとゲーマーの距離の近さ、およびハードウェアの電源 ゲームの品質にも大きな影響を与えますが、これは理想的なネットワークにも当てはまります。 サーバーへの ping が高すぎると、理想的なネットワークであっても快適にプレイできなくなります。 この研究では ping を実験しませんでした。

約束どおり、ここにリンクがあります すべての場合において、さまざまなサービスからの生のビデオ.

出所： habr.com