Zwiftのログを解析してビジュアルで視覚的に表現してくれる素敵なサービス、Zwiftalizerの使い方のメモ。毎度のことだが作者様に感謝
Zwiftalizerでできること
- 自分のZwift環境のグラフィックパフォーマンスのチェック
- センサー機器類それぞれの接続状況、通信品質、切断頻度の確認
- Zwiftサーバとの通信状況と通信品質、接続断の有無の確認
- 他のプレイヤーのグラフィックベンチマークの参照
上記の4のベンチマーク結果はサインイン不要で閲覧可能だが、1～3を実行するには、ログインアカウントを作成してサインインする必要がある。昔はログイン不要で全部できたのだが、色々と問題があるのだろう。。
Zwiftalizerの使い方
まずはサインイン
自分のログを読ませてナンボのサービスなので、まずは"Sign Up for Free"リンクからログインアカウントを作成する。適当なメールアドレスを指定してパスワードを設定するだけ。
サインインするとLog Readerに"Drop Log.txt file here or click to browse file system"と表示されログ読み込みができる状態になる
自分で読ませたログの解析
ログを放り込むと10～20秒程度で解析結果が表示される。最初にセッション概要、接続デバイス一覧、読ませたログに含まれるセッション一覧が表示される。このあたりは見たまんまで特に難しいことはない。
その下に続くのがメインのグラフィックパフォーマンス。以下のものが記載される。
- System/CPU/GPU：使っているOSとハードウェアの種別が表示される
- Profile：Zwiftでの画面品質設定プロファイルがどれになっているか。基本的にはGPUの種類によって勝手にZwiftが決めるものだが、設定ファイルを直接編集することでユーザが変更することも可能である
- Resolution：Zwiftの設定メニューから指定できる、Zwift上でのレンダリングの解像度ないしは品質。モニタの解像度とは別のものである点に注意
- P1：そのセッション内の全ての計測ポイントのなかで最もフレームレートが低い1%の平均値。計測ポイントは基本的に4秒ごとなので、例えば1時間のライドでは900回計測され、そのうち最もレートが低い9回(1%)の平均値がここに表示される。Avg(全部の平均)と比較して差が小さいのが好ましい。P1が極端に落ち込んでいる場合は、場面によってフレームレートの落ち幅が大きいことを示す
- Avg：全ての計測ポイントでのフレームレートの平均値。垂直同期オンの環境では、この値がモニタのリフレッシュレートに近ければ滑らかで快適なプレイができていると言っていい
- Max：セッション内での最大フレームレート。垂直同期オンの場合は基本的にはモニタのリフレッシュレートに近い値になる。可変フレームレートの環境では文字通りの最大値を示す
- Std Dev(Standard Deviation/標準偏差)：フレームレートのバラつき度合いを示す。この値が小さいほどフレームレートが常に同じ値で安定していると言える。値が大きければ変動が激しい。個人的には2以下なら快適。4から5以上になるとカクつきが気になってくる
続いてUDP Network Metrics。Zwiftではサーバーとクライアント間の通信にUDPという通信形式を採用していて、この状況と品質を示すのがこのセクションである。
- Max StC：サーバからクライアントに送られたUDPパケットの最大数/分。基本的にはコースの混雑度に比例する
- Avg StC：同じくセッション全体での平均UDPパケット数/分
- Max CtS：クライアントからサーバに送られたUDPパケットの最大数/分
- Avg StC：同じくセッション全体での平均UDPパケット数/分
- Rx Err：セッション内で受信エラーとなったUDPパケットの総数。ゼロであることが望ましい。この数が多い場合はネットワーク回線やPC/タブレット自体に問題ないしは能力不足である可能性がある
- Tx Err：同じく送信エラーとなったUDPパケットの総数。ゼロが基本
- Crowding %：周囲の混雑度を示す。Zwiftでは自分の周囲にいるライダーを最大100名まで処理でき、100名が周囲にいる状態が混雑度100%になる。上記の画像例では混雑度91%なので、セッション全体で平均して周囲に91名のライダーがいたことを示す。混雑するほどにCPUとGPUの使用率が上がり、ネットワーク越しにやりとりされるUDPパケット数が増える
- Crowding Tier：上記の混雑度を25%単位で区切って便宜的に区分けしたもの
- 100 - 76%：Packed (すし詰めだよ)
- 75 - 51%：Crowded (混んでるよ)
- 50 - 26%：Company (多少人がいるよ)
- 25 - 0%：Solo (ほぼソロライドだよ)
さらにその下に続くのはANT+/Bluetooth/TCP/UDP等の機器間やネットワーク接続の状況と品質。画像は我が家のANT+接続の心拍計とスマトレの例。
ANT+接続情報
ANT+を使ったセンサーデバイスと母艦の接続に関する情報。スマトレや心拍計など
- ANT+ Interference Channel X：ANT+で接続された各機器との通信。ANT+は1秒に4回シグナルを送信するが、そのうちどの程度がドロップ(サーバ側で受信失敗)したかをFail Rateで表す。ANT+はシンプルで軽量なプロトコルだが様々な外的要因に影響を受けやすく容易にドロップするので、グラフが賑やかなのはごく普通のこと。RxFailが15%以下ならばひとまずOKと中の人も言っている。プレイ中に機器の切断が頻繁に起こり、なおかつRxFailが15%を超えている、あるいは高いRxFailが連続している場合は、ANT+の接続不良の可能性が高いので環境を見直すか、Bluetoothの利用を検討する
- ANT+ FET Transfer Failures (Gradient/Resistance Change Failures)：Zwiftがスマトレに勾配の変化(＝負荷の変化)を送信したが、スマトレ側でそのシグナルを拾い損ねたイベントの数。イベントの母数が走るコースの起伏に依存するので、いくつなら良好というボーダーラインもない。ぶっちゃけあんまり役には立たないので「ふーん」でいいだろう。ANT+自体の接続は良好なのにこの数値だけは悪い、みたいな状況ではスマトレの不良が疑われるかもしれない
- ANT+ Disconnects：文字通りANT+の接続自体が切断された回数。ANT+は1秒に4回の送信を行い、これが8回連続して失敗すると接続自体を解除して再接続を試みる。前述のRxFailが少々高くても、この切断イベントが発生していなければプレイには大きな影響はない。切断イベントはZwiftでのストレスフルイベントランキング最上位なので、頻発する場合は環境の見直しを図るべき
Bluetooth接続情報
同じくBluetoothで接続されたデバイスとの通信に関わる情報群
- Bluetooth FTMS Message Resends：Zwiftサーバからスマートトレーナーに対して送信される勾配(負荷)変化のシグナルの受信にトレーナー側が失敗し、サーバーからの再送が発生した回数。頻発する場合はBluetoothの送受信環境がよろしくない可能性が考えられる
- Bluetooth Trainer Resets：再送が連続して規定回数をオーバーし、トレーナー側で負荷設定のリセットが行われた回数。これが頻発する場合は明らかに接続環境またはトレーナー自体に問題があるので要対策
- Bluetooth Disconnects：Bluetoothで接続したデバイスのいずれかとのコネクションが切断された回数。どのデバイスが切れたかはここからは分からない。このイベントが起きるとほとんどの場合は体感可能なパワーロスや心拍数のロスとなって現れる。走行中の発生回数はゼロであることが望ましい
UDP接続関連情報
UDPは主にZwiftのライド中のリアルタイムな情報交換に使われる。トレーナーのパワーや負荷変動、心拍数などのメトリクス、ゲーム内の他のライダーの位置情報など。この品質が低いとプレイ中に接続断やライダーの位置飛びなどが発生し不愉快な思いをすることになるので重要なところ。
- UDP Network Timeouts：Zwiftサーバからの定期的なポーリングを取りこぼした回数。少ないことが望ましいが、体感上の問題がなければあまり気にしなくていい。多発している場合は宅内またはインターネット側の回線品質に疑問符がつく
- UDP Network Errors：クライアント側からサーバへのデータ送信の失敗回数。これも基本的にはゼロに近いことが期待値だが、少数なら気にしなくていい
- UDP Network Disconnects：一定時間以上サーバからのUDPパケットが到達しないイベントが発生した回数。周辺ライダーの情報が届かなくなるので、挙動が怪しくなったりライダーの位置が飛んだり、長時間続くと周りに誰もいなくなったりする。ライド中の発生はゼロであることが望ましい
- UDP Network Connects：Zwiftサーバへのアクセスポイントは分散型で世界中に複数の接続先があるのだが、現在接続中のアクセスポイントとの通信が怪しくなるとクライアントは別のアクセスポイントに接続を切り替える動作をする。この回数がカウントされる。アクセスポイント側の混雑状況やインターネット側の状況に応じて発生するので、イベント回数は少ないに越したことはないがあまり利用者の側ではコントロールできる余地がない。UDP Network ErrorsやDisconnectsも多い場合はクライアント側の環境問題が疑われるが、この項目だけが多発しているという場合は無視して構わない、というか出来ることは多分ない
TCP接続情報
TCPは主にライド中以外の場面、例えばライド前のレース選択や設定画面の操作、新しいバージョンがリリースされた際のダウンロードやログのアップロードといったシーンで利用される。UDPよりも信頼性が高い通信方式なので、TCPだけエラーレートが高いというケースは考えづらい
- TCP Network Timeouts
- TCP Network Errors
- TCP Network Disconnects
その他
- Latency Test Failures：Zwiftサーバとクライアントとの間でのデータ送信遅延イベントの発生回数。ネットワークの経路上の何らかの要因によってデータの送信から受信までに時間がかかりすぎていて、スムーズなゲームプレイが妨げられるレベルで遅いと判断されたもの。このイベントが頻発している場合はネットワークの品質に課題がある可能性が高い。回線を別会社に変える、モバイルやWifiを有線接続に変更する、などの手段で遅延を減らすことを検討するべし
- World Clock Offset：あなたがZwiftをプレイしているデバイスとZwiftサーバで保持している時刻の差分。ライド中はその差分をZwiftアプリが検出して内部的に訂正を加えながらプレイが続行されている。この項目ではオフセット幅が少ないことが望ましいが、大事なのは数値そのものの大小よりも変動動幅が小さいこと。ライド中に大きく変動するとプレイ上の不自然な挙動や違和感になって現れる。変動を引き起こす原因としてはデバイス(PCやタブレット)の内部クロックの精度が怪しいか、通信経路の遅延の変動幅が大きいことなどが考えられる
自分のログを読む以外の使い方
他の人のベンチマークを見る
- World：文字通りZwiftのどのワールドでの記録か
- Profile：Zwift設定上での画面クオリティ
- Resolution：モニタの解像度
- Crowdedness：コースの混雑度
基本的にはFPSが高い記録から順番に表示される。高性能なゲーミングモニタを使っていたり、垂直同期でフレームレートにキャップをかけていない環境ではマシンの性能が上限まで発揮されるので上位に来やすい。例えば筆者の環境では60Hzのモニタで垂直同期をオンにしているので、Avg FPSは60以下になり、ベンチマーク画面では結構下のほうに表示されることになる。
また結果には新旧が入り混じっている。この手の数値は例えばGPUドライバの更新やZwift側の修正などの要因で突然大きく改善されたりするので、できるだけ新しい日付の結果を参考にするとよいだろう。
検索機能を使う
ベンチマークは普通に見ると縦に長いリストになってしまう。Search機能を使うと自分の知りたいCPUやGPU種別で結果を絞り込める。以下はIntelのArc A750で絞った例
CPU名やワールド名、プロファイル情報を追加指定してAND検索もできる。しかし内部的に何らかの制限があるらしく、ヒット数が多いと上位プロファイル結果しか表示されないようである。色々試してみるとよいだろう
以上、より快適なプレイ環境を求めるZwiftersにはとても有用なサイト、Zwiftalizersを紹介した。気に入ったならぜひ作者様に投げ銭をしよう。
