アプリに遅延とジッターを加える
高速なローカル接続なら、すべてが問題なく動きます。アプリに300 msのpingを与えると、応答が一瞬で返る前提で書かれた画面がどれかわかります。
3つの異なるもの
| 設定 | 何をするか | 現実での原因 |
|---|---|---|
| Latency | すべてのパケットに同じ遅延を加えます。単位はミリ秒です。 | 距離。別の大陸にあるサーバーや、衛星。 |
| Jitter | さらにランダムな量を上乗せし、遅延が絶えず変化するようにします。 | 共有Wi-Fi、モバイル回線、混雑したあらゆる回線。 |
| 遅延スパイク | ときどき起きる長い停止。発生頻度と長さで指定します。 | 基地局間のハンドオーバー、負荷のかかったルーター。 |
3つとも単位はミリ秒で、同時に使えます。2つの遅延の値はどちらも0以上なら何でも受け付けるので、現実的な40 msから、あり得ない60秒まで設定できます。
コマンドラインから
1つのアプリに、一定の200 msの遅延と80 msのジッターを加える例：
BeanNetworkTester.exe --latency 200 --jitter 80 --target myapp.exe --duration 60代わりに、まれに起きる長い停止を再現します。およそ20パケットに1つが、1秒余分に待たされます：
BeanNetworkTester.exe --spike-prob 5 --spike-ms 1000 --target myapp.exe試す価値のある数値
- 40 ms：同じ国内のサーバー。何も変わらないはずです。
- 150 ms：別の大陸。やり取りの多い処理は、往復のたびにコストがかかるため遅く感じ始めます。
- 600 ms以上：静止衛星や機内Wi-Fi。プログレスバーが止まり、再試行ロジックがようやく動く領域です。
用意済みのプロファイルには実測値が入っています：「Distant server (another continent)」「Satellite (low orbit)」「Satellite (geostationary)」「In-flight Wi-Fi」「LTE / 4G」。
測り方：平均ではなく、最悪のケースを見る
ジッターは平均値をほとんど動かさず、中央値もほとんど動かしません。ジッターが30 msある実行とない実行で、「典型的な」pingがほぼ同じに見えても、体感はまったく違うことがあります。
代わりに、95パーセンタイルと中央値を比べてください。両者の差がジッターであり、平均が問題なく見えるのに通話が途切れたりゲームが遊べなくなったりするのは、その差が原因です。