Wysoka latencja DPC nie oznacza wolnej ścieżki VPN

Glitch audio i pauza VPN wypadają w tych samych dziesięciu sekundach, a narzędzie raportuje wysoką liczbę oznaczoną jako latencja DPC. Kuszące jest wyciągnięcie wniosku, że sterownik spowalnia tunel albo że tunel obciąża sterownik. Żaden z tych wniosków nie wynika z tej liczby.

W grę wchodzą tu trzy pomiary i nie dzielą one tej samej granicy.

Trzy liczby, trzy granice

Odroczone wywołanie procedury to praca, którą sterownik odkłada ze swojego modułu obsługi przerwań, a czas spędzony wewnątrz tych procedur jest pomiarem lokalnym dla procesora przypisywanym modułom i funkcjom. Podróż echa w obie strony to obserwacja czasu na gnieździe, tworzona przez stos sieciowy i zdalnego odpowiadającego. Zdarzenie rozłączenia to przejście stanu zapisywane przez klienta. Każdy z nich odpowiada na pytanie, na które inne nie mogą, a identyczne jednostki nie czynią ich wymiennymi.

Pożyteczną dyscypliną jest nazwanie granicy przed odczytaniem wartości. Zapisz jednostkę i granicę obok siebie. Jeśli narzędzie raportuje milisekundy, zapytaj, milisekundy czego: czasu wewnątrz procedury, czasu oczekiwania na wykonanie czy czasu do nadejścia odpowiedzi.

Wysoka liczba w jednej kategorii to trop, nigdy diagnoza.

Przeczytaj definicję za nagłówkiem

Narzędzia różnią się tym, co nazywają latencją. Niektóre raportują czas trwania procedur sterownika, inne raportują opóźnienie planowania, a obie wielkości mogą poruszać się w przeciwnych kierunkach na tej samej maszynie. Panel, który jedną z nich nazywa po prostu latencją DPC, powiedział ci mniej, niż się wydaje. Dlatego dwa panele mogą się nie zgadzać co do maszyny, która wcale się nie zmieniła.

Ta sama ostrożność obowiązuje w obrębie jednego narzędzia analizy. Czas inkluzywny śledzi procedurę od wejścia do wyjścia, natomiast czas ekskluzywny sumuje tylko te fragmenty, w których sama procedura się wykonywała. Wybór niewłaściwej kolumny czyni wywołującego winowajcą.

Lokalna praca sterownika i opóźnienie sieci również oddziałują na siebie, nie łącząc się. Nadmierna aktywność związana z przerwaniami może opóźniać pracę wrażliwą na czas na maszynie, a zatłoczona ścieżka może opóźniać pakiety, i oba te fakty mogą być prawdziwe podczas jednej widocznej pauzy.

Umieść każdą obserwację w jednym oknie

Ślad jest użyteczny tylko wtedy, gdy czytasz przedział zawierający objaw. Zarejestruj ślad, zdarzenie klienta i awarię aplikacji ze znacznikami czasu, a następnie spójrz na te same sekundy we wszystkich trzech. Maksimum z godzinnego śladu i rozłączenie później tego popołudnia to dwa niepowiązane fakty.

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

Następnie otwórz ślad w narzędziu analizy i posortuj według czasu trwania w tym oknie, a nie według całego zapisu. wytyczne analizy procesora opisuje widok czasu trwania DPC/ISR, który przypisuje czas modułom i funkcjom.

Potwierdź, co naprawdę stało się z tunelem, póki tam jesteś. Krótka utrata ruchu aplikacji nie oznacza, że klient rozpoczął nowe negocjacje, a powodzenie małej sondy nie dowodzi, że wszystko inne nadal działało.

Zmień komponent, który wskazują dowody

Zajęty moduł to miejsce do zbadania, nie wyrok. Może wykonywać pracę wywołaną przez inny komponent lub przez obciążenie, które sam wytworzyłeś. Trzymaj razem nazwę modułu, urządzenie, wersję sterownika i obserwowany przedział, bo właśnie ten zestaw jest tym, na co dostawca może zareagować.

Jedna zmiana na eksperyment to jedyny sposób, by uczyć się z wyniku. Porównanie przewodowe zawęża zakres, ale jednocześnie zmienia ścieżkę radiową i aktywność sterownika, więc traktuj je jako trop, a nie dowód.

Traktuj ślad jako wrażliwy. Może zawierać nazwy procesów i szczegóły środowiska, więc jego miejsce jest w obsługiwanym kanale przechwytywania, a nie w publicznym załączniku. Powiedz, na jaką obserwację ślad miał odpowiedzieć.