Latence a jitter: co z toho vidí regulátor
Wi-Fi se prodává na propustnost a měří se na propustnost. Pro robota je to skoro nezajímavé číslo. Rozhoduje rozdělení zpoždění — a hlavně jeho pravý konec.
Z čeho se to zpoždění skládá
| složka | typicky | je to náhodné? |
|---|---|---|
| čekání na volný kanál | 0 – 5 ms | ano, podle zatížení |
| odpočítávání | 0 – 135 µs | ano, vždy |
| vysílání rámce | 50 – 2000 µs | ne, závisí na MCS a délce |
| opakování po kolizi | 0 – 30 ms | ano, a je to ocas |
| fronta v přístupovém bodu | 0 – ∞ | ano |
Dvě z těch pěti položek jsou náhodné z principu a nedají se odstranit. Jitter není vada konfigurace, je to vlastnost protokolu.
Průměr je k ničemu
Typický průměr v rozumně zatížené hale je 2–3 ms a vypadá skvěle. Jenže:
- p99 bývá 8–15 ms,
- p99,9 30–60 ms,
- nejhorší případ stovky milisekund, když se sejde opakování s roamingem.
Smyčka na 100 Hz má periodu 10 ms. Zpoždění p99 = 12 ms tedy znamená, že každý stý cyklus přijde pozdě — tedy jednou za sekundu. Regulátor, který na to není připravený, z toho dostane skok na akční veličině; jak přesně to škodí, ukazuje ServoLab.
Co s tím dělat
- Neregulovat přes Wi-Fi. Rychlá smyčka patří do měniče; přes rádio se posílají žádané hodnoty a stav. Tohle je ta jediná rada, která vždycky funguje.
- Rozpočítat si to. Perioda musí být násobkem p99,9, ne p50.
- Značkovat provoz (EDCA voice) a vypnout agregaci pro řídicí frontu.
- Míň stanic v buňce. Rozptyl roste s počtem soutěžících rychleji než průměr.
- Měřit, ne odhadovat. Rozdělení zpoždění se dá nasnímat za pár minut a je to nejlevnější diagnostika, jaká existuje.
Pozor na dvojí nesmysl s TCP. Přes Wi-Fi jede TCP dvakrát hůř, než čeká: rádio už rámce opakuje samo, takže když se ztráta projeví až do TCP, znamená to, že selhalo sedm pokusů. TCP to ale interpretuje jako přetížení a zpomalí — přesně v okamžiku, kdy je kanál volný a jen byl chvíli rušený. Pro řídicí provoz platí totéž co v NetLabu: spolehlivě ≠ včas.