Administrace komentářů

Tohle by chtělo doplňující informace. A bohužel docela dost doplňujících informací Úzkým hrdlem může být buď nízká kapacita spoje (a třeba do toho úzkého hrdla ani přímo nekoukají Vaše routery), nebo třeba procesorový výkon některého z VPN routerů po cestě. Zhruba na co koukat:

- okamžitý CPU load na jednotlivých routerech

- odkud kam ve Vaší topologii naskočí ten dlouhý delay = na kterém hopu.

Vyskytují se tu lidi s praktickými zkušenostmi - pokud jim řeknete, jaké jsou kde procesory a při jak rychlém přenosu (kBps/pps) Vám to stropuje, třeba se podělí o názor, jestli to je/není v pořádku.

Pokud se CPU na routerech flákají, může být ten dlouhý round-trip způsobený dlouhou frontou na vstupu do úzkého hrdla: na egressu, do L3/L2 rozhraní, a to buď na krabičce ve Vaší správě, nebo v krabičce některého providera po cestě = mimo Vaši pravomoc

Teorie hromadné obsluhy praví, že pokud na nějakou zpracující jednotku (úzké hrdlo) hrnete požadavky v průměru rychleji, než kolik stíhá zpracovat, délka fronty přestane konvergovat k nule, resp. začne od nuly divergovat (k nekonečnu). Jak dlouhá fronta naroste (v počtu požadavků resp. v časových jednotkách = zpoždění) než se začnou pakety zahazovat, to je na routeru dáno nějakým konfiguračním parametrem, a je otázkou, zda je tento konfigurační parametr laditelný administrátorem Fronta o nějaké netriviální délce má dvojí význam: pobere nadrobený/dávkovitý provoz a v jistých mezích (reálná zátěž těsně pod maximem) zajistí optimální využití spoje tím, že některé pakety pozdrží = "vyhladí tok dat v čase" - a druhá věc je, že slušně vychované TCP při mírném přetížení sítě či jednotlivého spoje zareaguje zpomalením přenosu (právě díky zpoždění ve frontě kdesi po cestě), aniž by došlo ke ztrátám paketů. Zpoždění ve frontě interaguje s TCP Window na koncových bodech. Tzn. netvrdil bych kategoricky, že dlouhé fronty jsou zlo. Všechno je relativní, záleží na aplikaci. Ta problematika má spoustu dalších nuancí, viz třeba priorizace (fronty s předbíháním), kde má smysl shapovat/priorizovat (nejlépe přímo na vstupu do úzkého hrdla, nikoli o kus dál), random early detection (říkal jste, že roste ztrátovost?) apod. A zřejmě platí axiom, že surovou kapacitu (průchodnost) ničím nenahradíte, nebo přinejmenším shapingem nenahoníte.

Pokud by se Vám vyskytla situace, že se procesory flákají, linky se flákají, a přesto vidíte dlouhé latence, tak to by teprve bylo to pravé žůžo Pak začnete zkoumat, co máte kde za síťovky, nakolik efektivně pracují s interrupty a buffery apod. Pokud to má smysl na daném hardwaru řešit.