NetDiag+

Pruebas que tu operador no puede quitarse de encima

«Por las noches internet va lento» es una sensación, y al soporte lo entrenan para responder a las sensaciones con un reinicio del router. Un número con un lugar y una hora es otra conversación: la pérdida de paquetes empieza en mi tercer salto cada noche a partir de las nueve, aquí están las ejecuciones. Tres mediciones hacen ese trabajo — dónde empieza la pérdida, cómo se comporta la latencia bajo carga y qué tan lejos e inestables están los servidores que usas de verdad — y desde NetDiag+ 1.4.6 cada una se exporta como texto plano que puedes pegar en una incidencia, un foro o el formulario del regulador.

Tres mediciones que nombran un lugar y una hora

  1. Localiza la pérdida con MTR. Un traceroute que sigue haciendo ping a cada salto muestra dónde empiezan a desaparecer los paquetes. La pérdida que empieza en un salto y persiste hasta el final es real, y ese salto nombra la red responsable. La pérdida en un solo salto que desaparece en el siguiente es ese router limitando sus propias respuestas — normal, no es prueba. Ejecútalo a la hora mala y anota el salto.
  2. Añade la latencia bajo carga y la tabla de latencia. Un test de bufferbloat te dice cuánto sube la latencia con la línea ocupada y en qué dirección: un pico al subir apunta a tu propio router, un pico al descargar al equipo del operador — y esa dirección es lo que decide de quién es el problema. El Panel de latencia añade mediana, jitter y pérdida a los servidores concretos que usas, midiendo primero tu propio router para que nadie pueda culpar a tu Wi-Fi si está limpio.
  3. Exporta como texto, a las horas correctas, más de una vez. Cada herramienta tiene Compartir → informe de texto: destinos, marcas de tiempo, todos los números. Una ejecución no demuestra nada; tres a la hora mala en días distintos más una a una hora tranquila como control es un patrón. El gráfico de tendencia de bufferbloat guarda el peor pico de cada ejecución durante 7, 30 o 90 días, así que el patrón se ve sin que tomes notas. El historial guarda todo lo que ejecutaste.
Descargar en el App Store

Gratis · 27 herramientas · compra única para quitar los anuncios · sin suscripción

Preguntas que la gente hace de verdad

¿Qué debe contener exactamente la incidencia?

Fechas y horas de cada ejecución. El salto donde empieza la pérdida y su porcentaje. Latencia en reposo frente a latencia con descarga y con subida. Mediana y jitter a dos o tres servidores que use tu casa. Cuál fue el test de control. Todo pegado como texto, no descrito — un técnico puede actuar sobre una lista de saltos, no sobre «va a tirones».

El soporte dice que la línea está bien. ¿Mienten?

Normalmente no. Sus pruebas revisan niveles de señal, contadores de errores y caudal, y todo eso puede ser perfecto mientras una cola añade 300 ms o un enlace de interconexión saturado tira el 2% de los paquetes a las nueve de la noche. Estás midiendo algo que ellos no miden. Dilo y pásales los números.

¿Capturas de pantalla o texto?

Texto. Se puede buscar, citar, pegar en una herramienta interna y reenviar al ingeniero que de verdad arregla cosas; una captura no. El texto también sobrevive a la compresión de imágenes de un foro y al formulario web de un regulador. Guárdate las capturas para ti.

¿Cuántas ejecuciones hacen un caso?

Las suficientes para mostrar que el problema se repite y depende de la hora. Tres ejecuciones a la hora mala en dos o tres días, más una a una hora buena que salga limpia, es el mínimo que convierte una queja en un informe. Si la de la hora buena también sale mal, la causa no es la congestión — eso también sirve.

¿Esto de verdad consigue que arreglen algo?

Mueve la incidencia del primer nivel a alguien que sepa leer una lista de saltos, que es el paso donde suele atascarse. Donde hay regulador, los formularios de reclamación piden exactamente esto: fechas, mediciones, qué respondió el operador. Las pruebas no garantizan un arreglo; quitan las razones para decir no.

El número más contundente de todo esto es la latencia bajo carga. Siguiente: qué servidor está lejos y cuál es inestable →