O latență DPC mare nu înseamnă o cale VPN lentă

Un defect audio și o pauză VPN cad în aceleași zece secunde, iar un utilitar raportează o valoare mare etichetată ca latență DPC. Tentația este să concluzionăm că driverul încetinește tunelul sau că tunelul solicită driverul. Niciuna dintre cele două concluzii nu decurge din acea cifră.

Aici sunt implicate trei măsurători și nu împart aceeași graniță.

Trei numere, trei granițe

Un apel de procedură amânat este muncă pe care un driver o amână din handlerul său de întreruperi, iar timpul petrecut în aceste rutine este o măsurătoare locală procesorului atribuită modulelor și funcțiilor. Un dus-întors de ecou este o observație de timp la socket, produsă de o stivă de rețea și de un respondent îndepărtat. Un eveniment de deconectare este o tranziție de stare înregistrată de client. Fiecare răspunde la o întrebare la care celelalte nu pot, iar unitățile identice nu le fac interschimbabile.

Disciplina utilă este să numești granița înainte de a citi valoarea. Scrieți unitatea și granița una lângă alta. Dacă un instrument raportează milisecunde, întrebați milisecunde din ce: timp din interiorul unei rutine, timp de așteptare pentru rulare sau timp până la sosirea unui răspuns.

O cifră mare într-o categorie este un indiciu, niciodată un diagnostic.

Citiți definiția din spatele titlului

Utilitarele diferă în ceea ce numesc latență. Unele raportează durata rutinelor driverului, altele raportează întârzierea de planificare, iar cele două mărimi se pot mișca în direcții opuse pe aceeași mașină. Un panou care numește una dintre ele pur și simplu latență DPC v-a spus mai puțin decât pare. De aceea două panouri pot să nu fie de acord despre o mașină care nu s-a schimbat deloc.

Aceeași prudență se aplică în interiorul unui singur instrument de analiză. Durata incluzivă urmărește o rutină de la intrare la ieșire, în timp ce durata exclusivă însumează doar fragmentele în care rutina însăși se executa. Alegerea coloanei greșite transformă apelantul în vinovat.

Munca locală a driverului și întârzierea rețelei interacționează și ele fără să fuzioneze. Activitatea excesivă legată de întreruperi poate întârzia munca sensibilă la timp pe mașină, iar o cale congestionată poate întârzia pachetele, și ambele pot fi adevărate în timpul unei singure pauze vizibile.

Puneți fiecare observație într-o singură fereastră

O urmărire este utilă doar dacă citiți intervalul care conține simptomul. Înregistrați urmărirea, evenimentul clientului și eșecul aplicației cu marcaje de timp, apoi priviți aceleași secunde în toate trei. Un maxim dintr-o urmărire de o oră și o deconectare mai târziu în acea după-amiază sunt două fapte fără legătură.

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

Apoi deschideți urmărirea în instrumentul de analiză și sortați după durată în acea fereastră, nu după întreaga captură. ghidul de analiză a procesorului descrie vizualizarea duratei DPC/ISR care atribuie timpul modulelor și funcțiilor.

Confirmați ce s-a întâmplat de fapt cu tunelul cât timp sunteți acolo. Pierderea scurtă a traficului aplicației nu înseamnă că clientul a început o negociere nouă, iar succesul unei mici sondări nu dovedește că tot restul a continuat să funcționeze.

Schimbați componenta pe care o indică dovezile

Un modul ocupat este un loc de investigat, nu o sentință. Poate executa muncă provocată de altă componentă sau de sarcina pe care ați generat-o. Țineți împreună numele modulului, dispozitivul, versiunea driverului și intervalul observat, pentru că acest set este ceea ce poate folosi un furnizor.

O singură schimbare pe experiment este singura cale de a învăța din rezultat. O comparație prin cablu restrânge domeniul, dar modifică simultan calea radio și activitatea driverului, așa că tratați-o ca indiciu, nu ca dovadă.

Tratați urmărirea ca sensibilă. Poate conține nume de procese și detalii despre mediu, așa că îi este locul în canalul de captură acceptat, nu într-un atașament public. Spuneți la ce observație trebuia să răspundă urmărirea.