Vysoká latence DPC neznamená pomalou cestu VPN

Zvuková porucha a pauza VPN spadnou do stejných deseti sekund a nástroj hlásí vysokou hodnotu označenou jako latence DPC. Láká to uzavřít, že ovladač zpomaluje tunel, nebo že tunel zatěžuje ovladač. Ani jeden z těchto závěrů z toho čísla nevyplývá.

Ve hře jsou tři měření a nesdílejí stejnou hranici.

Tři čísla, tři hranice

Odložené volání procedury je práce, kterou ovladač odkládá ze svého obslužného rutinu přerušení, a čas strávený uvnitř těchto rutin je měření místní pro procesor, přiřazené modulům a funkcím. Echo tam a zpět je pozorování času na socketu, které vytváří síťový stack a vzdálený odpovídač. Událost odpojení je přechod stavu zaznamenaný klientem. Každé odpovídá na otázku, na kterou ostatní nedokážou, a shodné jednotky je nečiní zaměnitelnými.

Užitečná disciplína je pojmenovat hranici dřív, než přečtete hodnotu. Napište jednotku a hranici vedle sebe. Pokud nástroj hlásí milisekundy, ptejte se milisekundy čeho: času uvnitř rutiny, času čekání na spuštění, nebo času do příchodu odpovědi.

Vysoké číslo v jedné kategorii je stopa, nikdy diagnóza.

Přečtěte si definici za titulkem

Nástroje se liší v tom, co nazývají latencí. Některé hlásí trvání rutin ovladače, jiné hlásí zpoždění plánování a obě veličiny se mohou na stejném stroji pohybovat opačnými směry. Panel, který jednu z nich nazve prostě latencí DPC, vám řekl méně, než to vypadá. Dva panely se proto mohou rozcházet u stroje, který se vůbec nezměnil.

Stejná opatrnost platí i uvnitř jednoho analytického nástroje. Inkluzivní trvání sleduje rutinu od vstupu k výstupu, kdežto exkluzivní trvání sčítá jen fragmenty, v nichž se daná rutina sama vykonávala. Volba špatného sloupce udělá z volajícího viníka.

Místní práce ovladače a síťové zpoždění také působí společně, aniž by splývaly. Nadměrná aktivita související s přerušeními může zpozdit práci citlivou na čas ve stroji a přetížená cesta může zpozdit pakety a obojí může platit během jedné viditelné pauzy.

Umístěte každé pozorování do jednoho okna

Trasování je užitečné jen tehdy, když čtete interval, který obsahuje symptom. Zaznamenejte trasování, událost klienta a selhání aplikace s časovými značkami a pak se podívejte na stejné sekundy ve všech třech. Maximum z hodinového trasování a odpojení později toho odpoledne jsou dva nesouvisející fakty.

wpr -start CPU -filemode
wpr -stop vpn-trace.etl
xperf -i vpn-trace.etl -a dpcisr -o dpc.txt

Potom otevřete trasování v analytickém nástroji a seřaďte podle trvání uvnitř tohoto okna, ne podle celého záznamu. pokyny pro analýzu procesoru popisuje pohled na trvání DPC/ISR, který přiřazuje čas modulům a funkcím.

Potvrďte, co se tunelu skutečně stalo, dokud jste tam. Krátká ztráta provozu aplikace neznamená, že klient zahájil nové vyjednávání, a úspěch malé zkoušky nedokazuje, že všechno ostatní dál fungovalo.

Změňte komponentu, kterou důkazy označují

Zaneprázdněný modul je místo k vyšetřování, ne rozsudek. Může vykonávat práci způsobenou jinou komponentou nebo zátěží, kterou jste vytvořili. Držte pohromadě název modulu, zařízení, verzi ovladače a pozorovaný interval, protože právě tato sada je to, s čím dodavatel může pracovat.

Jedna změna na experiment je jediný způsob, jak se z výsledku učit. Kabelové srovnání zužuje rozsah, ale zároveň mění rádiovou cestu i aktivitu ovladače, takže je berte jako stopu, ne jako důkaz.

Berte trasování jako citlivé. Může obsahovat názvy procesů a podrobnosti o prostředí, proto patří do podporovaného kanálu pro zachytávání, ne do veřejné přílohy. Řekněte, na které pozorování mělo trasování odpovědět.