Unha latencia DPC alta non significa unha ruta VPN lenta

Un fallo de audio e unha pausa da VPN caen nos mesmos dez segundos, e unha utilidade informa dunha cifra alta etiquetada como latencia DPC. A tentación é concluír que o controlador está a frear o túnel, ou que o túnel está a estresar o controlador. Ningunha das dúas conclusións se desprende desa cifra.

Aquí interveñen tres medicións, e non comparten a mesma fronteira.

Tres cifras, tres fronteiras

Unha chamada de procedemento adiada é traballo que un controlador pospón desde o seu xestor de interrupcións, e o tempo pasado dentro desas rutinas é unha medición local do procesador atribuída a módulos e funcións. Unha viaxe de ida e volta de eco é unha observación de tempo no socket, producida por unha pila de rede e un respondedor remoto. Un evento de desconexión é unha transición de estado rexistrada polo cliente. Cada unha responde a unha pregunta que as outras non poden, e as unidades coincidentes non as fan intercambiables.

A disciplina útil é nomear a fronteira antes de ler o valor. Escriba a unidade e a fronteira unha xunto da outra. Se unha ferramenta informa de milisegundos, pregunte milisegundos de que: tempo dentro dunha rutina, tempo agardando para executarse ou tempo ata que chegou unha resposta.

Unha cifra alta nunha categoría é unha pista, nunca un diagnóstico.

Lea a definición detrás do titular

As utilidades difiren no que chaman latencia. Algunhas informan da duración das rutinas do controlador, outras informan do atraso de planificación, e ambas as cantidades poden moverse en direccións opostas na mesma máquina. Un panel que chama a unha delas simplemente latencia DPC díxolle menos do que parece. Por iso dous paneles poden discrepar sobre unha máquina que non cambiou en absoluto.

A mesma precaución aplícase dentro dunha soa ferramenta de análise. A duración inclusiva segue unha rutina desde a entrada ata a saída, mentres que a duración exclusiva só suma os fragmentos nos que esa rutina estaba executando. Escoller a columna incorrecta converte un chamador en culpable.

O traballo local do controlador e o atraso de rede tamén interactúan sen fundirse. Unha actividade excesiva relacionada con interrupcións pode atrasar traballo sensible ao tempo na máquina, e unha ruta conxestionada pode atrasar paquetes, e ambas as cousas poden ser certas durante unha mesma pausa visible.

Poña cada observación nunha soa xanela

Unha traza só é útil se le o intervalo que contén o síntoma. Rexistre a traza, o evento do cliente e o fallo da aplicación con marcas de tempo, e despois mire os mesmos segundos nos tres. Un máximo dunha traza dunha hora e unha desconexión máis tarde esa tarde son dous feitos non relacionados.

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

Despois abra a traza na ferramenta de análise e ordene por duración dentro desa xanela, en lugar de por toda a captura. A guía de análise de CPU describe a vista de duración DPC/ISR que atribúe tempo a módulos e funcións.

Confirme que ocorreu realmente co túnel mentres está alí. Perder brevemente o tráfico da aplicación non significa que o cliente iniciase unha negociación nova, e o éxito dunha sonda pequena non demostra que todo o demais seguise funcionando.

Cambie o compoñente que sinalan as probas

Un módulo ocupado é un lugar onde investigar, non un veredicto. Pode estar facendo traballo causado por outro compoñente ou pola carga que vostede xerou. Manteña xuntos o nome do módulo, o dispositivo, a versión do controlador e o intervalo observado, porque ese conxunto é o que un provedor pode usar.

Un cambio por experimento é a única forma de aprender do resultado. Unha comparación por cable estreita o alcance, pero cambia a ruta de radio e a actividade do controlador ao mesmo tempo, así que trátea como unha pista e non como unha proba.

Trate a traza como sensible. Pode conter nomes de procesos e detalles da contorna, así que pertence á canle de captura admitida e non a un anexo público. Diga que observación debía responder a traza.