Nastavte rozpočet zpoždění pro provoz v reálném čase přes VPN

Stížnosti na VPN v reálném čase potřebují termín, proti kterému mohou selhat, a „nízká latence“ takovým termínem není. Rozhodněte, co musí hovor nebo vzdálená relace dodat, a potom změřte cestu proti tomuto požadavku za uvedených podmínek. Bez prahu pro pozdní pakety je každý výsledek sporný. Rozdělení níže je návrhové rozhodnutí a existuje proto, aby měření mělo na co odpovědět.

Napište termín, než se dotknete sondy

Termín přichází od aplikace a jejích uživatelů, ne z marketingové stránky dodavatele. Živý hlasový hovor, relace vzdálené plochy a noční záloha snášejí zcela různé čekací doby a selhání, na kterém záleží, je obvykle ocas, nikoli medián. Napište číslo spolu se zátěží, ke které patří.

Potom ho rozdělte. Zachytávání a paketizace spotřebují část rozpočtu, přístupový spoj a tunel další část, přijímací de-jitter buffer drží pakety záměrně a zpracování aplikace bere zbytek. Pojmenování těchto fází drží šifrování tunelu v proporci, místo aby se stalo výchozím podezřelým pro každý pomalý paket.

Nakonec definujte smlouvu o měření ve čtyřech řádcích: koncové body a směr, tvar provozu, podmínky během běhu a výsledek, který oznámíte. Tichý nedělní vzorek a zatížený úterní vzorek odpovídají na různé otázky, proto uveďte, který jste pořídili. Pokud nemůžete vyplnit všechny čtyři řádky, běh není připraven začít. Tento kontrolní seznam je také to, co dělá dvě zprávy srovnatelné měsíce poté, kdy si už nikdo nepamatuje, co dalšího spoj nesl.

Rozdělte rozpočet na každou fázi

Tabulka je plánovací pomůcka, ne zachycená data. Vyplňte vlastníka každého řádku před první sondou, protože vlastník je ten, komu voláte, když tato fáze překročí svůj podíl.

Dva řádky lidi obvykle překvapí. Přijímací buffer není závada, když přidává zpoždění, protože dělá práci, pro kterou byl nastaven. A podíl tunelu je často menší než fronta před ním, zvláště na vzestupném spoji, který se při nahrávání nasytí.

Když fáze nemá vlastníka, je rozpočet fikce. Přiřaďte ho před měřením, jinak strávíte příští schůzku hádkou o tom, čí číslo je špatné.

Změřte jednostranné zpoždění poctivými hodinami

Jednostranné zpoždění je číslo, na kterém termínu záleží, a vyžaduje synchronizované hodiny na obou koncích. Metrika jednostranného zpoždění vyžaduje, abyste spolu s výsledkem uvedli metodu synchronizace, rozlišení a odhadovaný posun. Dva nesynchronizované hostitele mohou vytvořit velmi přesné číslo pro špatnou veličinu.

Zachyťte několik stovek paketů místo hrstky a zaznamenejte stav hodin ve stejnou dobu:

$ ntpq -p
$ owping -c 300 -i 0.2 10.90.0.1
$ ping -c 200 -i 0.2 10.90.0.1 | tail -n 3

Doba obratu je samostatné měření, ne dvě jednostranné hodnoty sečtené dohromady. Poloviční RTT předpokládá symetrické cesty a symetrické fronty a tunel přes mobilní vzestupný spoj oba předpoklady pravidelně boří. Vykazujte RTT jako RTT a držte ho mimo jednostranný rozpočet.

Vykazujte ocas a pozdní pakety

Shrňte rozdělení: medián, 95. a 99. percentil, nejhorší případ, ztrátu a počet paketů, které dorazily později, než termín dovoluje. Průměr je z těchto čísel pro zátěž v reálném čase nejméně užitečný, protože hladký průměr může skrýt ocas, který ničí každý třetí hovor.

Kolísání zpoždění přímo napájí buffer přijímače. Více bufferování skrývá kolísání a přidává čekání, takže stream může vypadat stabilně, i když překračuje svůj termín. Zvolte formulaci kolísání, uveďte interval, přes který jste měřili, a udržujte ji konzistentní mezi běhy.

Zopakujte běh s reprezentativním křížovým provozem. Cesta, která splňuje rozpočet v klidu a minuje ho během okna zálohování, vám řekla něco užitečného o plánování, co by žádné jediné tiché měření neodhalilo. Zaznamenejte podmínky vedle výsledku, protože příští inženýr jinak porovná dva vzorky, které nikdy srovnatelné nebyly.

Přijměte návrh, když se změřený ocas vejde do rozpočtu při zátěži, kterou skutečně provozujete, a odmítněte ho s uvedením fáze, která překročila limit, ve zprávě.