Přidání zpoždění a jitteru aplikaci
Na rychlém lokálním spojení všechno funguje. Dejte aplikaci 300 ms pingu a zjistíte, které obrazovky byly napsány, jako by odpověď přišla okamžitě.
Tři různé věci
| Nastavení | Co dělá | Odkud se to bere v reálném životě |
|---|---|---|
| Latency | Přidá každému paketu stejné zpoždění v milisekundách. | Vzdálenost. Server na jiném kontinentu nebo družice. |
| Jitter | Přidá navíc náhodnou hodnotu, takže se zpoždění pořád mění. | Sdílené WiFi, mobilní sítě, cokoli přetíženého. |
| Skoky | Občasná dlouhá zadrhnutí, daná tím, jak často a jak dlouho. | Předání mezi základnovými stanicemi, přetížený router. |
Všechny tři jsou v milisekundách a mohou běžet společně. Obě hodnoty zpoždění přijímají cokoli od 0 výše, takže se dostanete od uvěřitelných 40 ms k absurdním 60 sekundám.
Z příkazového řádku
Stálých 200 ms s 80 ms jitteru, u jedné aplikace:
BeanNetworkTester.exe --latency 200 --jitter 80 --target myapp.exe --duration 60Místo toho vzácná dlouhá zadrhnutí: zhruba jeden paket z dvaceti čeká o sekundu navíc:
BeanNetworkTester.exe --spike-prob 5 --spike-ms 1000 --target myapp.exeČísla, která stojí za vyzkoušení
- 40 ms: server ve stejné zemi. Nic by se nemělo změnit.
- 150 ms: jiný kontinent. Všechno upovídané začne působit pomalu, protože každá okružní cesta něco stojí.
- 600 ms a víc: geostacionární družice nebo WiFi v letadle. Tady se zasekávají ukazatele průběhu a konečně se spustí logika opakování.
Hotové profily nesou naměřené hodnoty: „Distant server (another continent)“, „Satellite (low orbit)“, „Satellite (geostationary)“, „In-flight Wi-Fi“, „LTE / 4G“.
Měření: dívejte se na nejhorší případ, ne na průměr
Jitter průměr sotva pohne a medián také. Běh s 30 ms jitteru a běh bez něj mohou hlásit skoro stejný „typický“ ping, a přitom působit úplně jinak.
Porovnávejte raději 95. percentil s mediánem. Rozdíl mezi nimi je jitter a právě ten dělá hlasový hovor sekaným a hru nehratelnou, zatímco průměr pořád vypadá v pořádku.