Latência DPC alta não significa um caminho VPN lento

Uma falha de áudio e uma pausa da VPN caem nos mesmos dez segundos, e um utilitário relata um valor alto rotulado como latência DPC. A tentação é concluir que o driver está atrasando o túnel, ou que o túnel está sobrecarregando o driver. Nenhuma das duas conclusões decorre desse número.

Há três medições em jogo aqui, e elas não partilham a mesma fronteira.

Três números, três fronteiras

Uma chamada de procedimento adiada é trabalho que um driver adia do seu manipulador de interrupções, e o tempo passado dentro dessas rotinas é uma medição local ao processador atribuída a módulos e funções. Uma ida e volta de eco é uma observação de tempo no socket, produzida por uma pilha de rede e um respondente remoto. Um evento de desconexão é uma transição de estado registada pelo cliente. Cada uma responde a uma pergunta que as outras não conseguem, e unidades iguais não as tornam intercambiáveis.

A disciplina útil é nomear a fronteira antes de ler o valor. Escreva a unidade e a fronteira lado a lado. Se uma ferramenta relata milissegundos, pergunte milissegundos de quê: tempo dentro de uma rotina, tempo à espera de executar ou tempo até chegar uma resposta.

Um valor alto numa categoria é uma pista, nunca um diagnóstico.

Leia a definição por trás da manchete

Os utilitários diferem no que chamam latência. Alguns relatam a duração das rotinas do driver, outros relatam o atraso de escalonamento, e as duas grandezas podem mover-se em direções opostas na mesma máquina. Um painel que chama a uma delas simplesmente latência DPC disse-lhe menos do que parece. Por isso dois painéis podem discordar sobre uma máquina que não mudou nada.

A mesma cautela aplica-se dentro de uma única ferramenta de análise. A duração inclusiva segue uma rotina da entrada à saída, enquanto a duração exclusiva soma apenas os fragmentos em que essa rotina estava a executar. Escolher a coluna errada transforma um chamador em culpado.

O trabalho local do driver e o atraso de rede também interagem sem se fundirem. Uma atividade excessiva relacionada com interrupções pode atrasar trabalho sensível ao tempo na máquina, e um caminho congestionado pode atrasar pacotes, e ambas as coisas podem ser verdade durante uma mesma pausa visível.

Coloque cada observação numa única janela

Um rastreio só é útil se ler o intervalo que contém o sintoma. Registe o rastreio, o evento do cliente e a falha da aplicação com marcas temporais, e depois olhe para os mesmos segundos nos três. Um máximo de um rastreio de uma hora e uma desconexão mais tarde nessa tarde são dois factos sem relação.

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

Depois abra o rastreio na ferramenta de análise e ordene por duração dentro dessa janela, em vez de por toda a captura. O guia de análise da CPU descreve a vista de duração DPC/ISR que atribui tempo a módulos e funções.

Confirme o que aconteceu realmente ao túnel enquanto estiver lá. Perder brevemente o tráfego da aplicação não significa que o cliente iniciou uma nova negociação, e o sucesso de uma pequena sonda não prova que tudo o resto continuou a funcionar.

Troque o componente que as evidências indicam

Um módulo ocupado é um lugar para investigar, não um veredicto. Pode estar a fazer trabalho causado por outro componente ou pela carga que gerou. Mantenha juntos o nome do módulo, o dispositivo, a versão do driver e o intervalo observado, porque esse conjunto é o que um fornecedor pode usar.

Uma alteração por experiência é a única forma de aprender com o resultado. Uma comparação por cabo estreita o âmbito, mas altera ao mesmo tempo o caminho de rádio e a atividade do driver, por isso trate-a como pista e não como prova.

Trate o rastreio como sensível. Pode conter nomes de processos e detalhes do ambiente, por isso pertence ao canal de captura suportado e não a um anexo público. Diga a que observação o rastreio devia responder.