¿Cuáles son algunas técnicas para rastrear las causas raíz de retrasos intermitentes, a veces muy prolongados, en las sesiones de TigerVNC?
Trabajar de forma remota vía SSH usando TigerVNC. La mayor parte del tiempo la pantalla responde. Sin embargo, muchas veces al día hay retrasos en la respuesta; estos pueden variar desde medio segundo hasta variosminutos, con los caracteres escritos y el movimiento y las acciones del mouse que permanecen almacenados en el búfer. Esto es muy perturbador cuando ocurre en medio de la escritura de una línea de código.
Durante estos retrasos, los pings se realizan (hasta ahora) sin ningún problema y otros accesos a Internet funcionan bien.
Estamos en ComCast con un plan de rendimiento relativamente alto. El WiFi no es un problema, ya que mi computadora portátil está conectada a través de un interruptor a nuestro enrutador/módem por cable. La empresa para la que trabajo tiene un ISP diferente. Dice que otros con ComCast han tenido problemas similares, sin embargo, actualmente no hay otras opciones de ISP disponibles donde vivo.
Un traceroute (ligeramente redactado)...pausasen el salto 9 y espectáculos * * *para ese salto.
scott@scott-HP-Pavilion-15-dk0xxx:~$ traceroute <redacted>.com
traceroute to <redacted> (<redacted>), 64 hops max
1 192.168.0.1 0.660ms 1.224ms 0.691ms
2 <redacted> 12.768ms 13.083ms 9.222ms
3 24.153.80.113 12.028ms 9.766ms 10.039ms
4 69.139.164.217 11.650ms 17.848ms 10.298ms
5 24.124.128.249 14.816ms 10.285ms 10.711ms
6 68.86.93.165 11.076ms 15.245ms 11.115ms
7 96.110.40.89 11.764ms 12.553ms 10.458ms
8 96.110.32.234 10.686ms 9.901ms 10.849ms
9 * * * <--- this part runs slowly.
10 64.125.23.46 11.342ms 9.551ms 8.964ms
11 64.125.29.3 10.094ms 11.916ms 11.782ms
12 64.125.36.106 11.953ms 9.912ms 9.900ms
13 <redacted> 14.820ms 9.314ms 10.101ms
14 <redacted> 12.224ms 9.792ms 10.748ms
15 <redacted> 10.585ms 11.545ms 12.545ms
16 * * *
...
64 * * *
Hasta ahora, una llamada al soporte técnico de Comcast ha producido un número de ticket de soporte, un intento quizás reflexivo de obligarme a cambiar nuestro módem por cable (bastante nuevo) y (hasta la fecha) ninguna llamada devuelta. Sin embargo, el problema no es la baja velocidad durante el funcionamiento normal y nuestra conexión no se cae (que yo sepa); Los pings y otros accesos a Internet continúan funcionando sin demoras durante las pausas, y las pulsaciones de teclas y las acciones del mouse permanecen almacenadas en el búfer.
Agradecería cualquier idea para:
- ¿Cómo aislar el problema del software, un problema de red o?
- Herramientas para ayudar a aislar
- Si es lo último, cómo decirle a nuestro ISP qué está mal, con la esperanza de que esto llegue a alguien con acceso para solucionarlo.
- Cómo superar esto (posiblemente alquilando una oficina donde haya otro ISP disponible)
Editar: por sugerencia de uso sudo journalctl -b 0 -u NetworkManager:
los registros muestran muchos tripletes de:
connectivity: (en01) timed out, seguido inmediatamente por:manager: NetworkManager state is now CONNECTED_SITE,- Luego, después de un retraso de 4 minutos y 31 segundos (?) cada vez:
manager: NetworkManager state is now CONNECTED_GLOBALsecuencias.
Ejemplo, con el nombre del sistema recortado:
Oct 24 17:14:06 <name> NetworkManager[1065]: <info> [1635120846.1948] connectivity: (eno1) timed out
Oct 24 17:14:06 <name> NetworkManager[1065]: <info> [1635120846.1949] manager: NetworkManager state is now CONNECTED_SITE
Oct 24 17:18:37 <name> NetworkManager[1065]: <info> [1635121117.3196] manager: NetworkManager state is now CONNECTED_GLOBAL
Respuesta1
Los paquetes IP tienen un campo de tiempo de vida diseñado para evitar que los paquetes se repita para siempre.
Cada enrutador debe reducir el campo TTL cada vez que se reenvía el paquete.
Cuando el TTL cae por debajo de 1, el enrutador debe devolver un paquete ICMP indicando que el campo TTL ha caducado. Además debe soltar el paquete.
traceroutefunciona enviando 3 paquetes con TTL 1 y escuchando los paquetes ICMP. Informa el tiempo requerido y de dónde provino el informe. Luego envía 3 paquetes con TTK 2 e informa los hosts y las horas. Un TTL de 3, luego un TTL de 4 y así sucesivamente. Sin embargo, el programa no espera indefinidamente. Si no recibe una respuesta ICMP, imprime un archivo *.
Entonces, para TTL de 9 no se reciben respuestas ICMP. Esto podría deberse a que el enrutador está configurado para no enviar respuestas o puede haber reglas de firewall que bloqueen los paquetes. La lentitud sólo espera las respuestas.
Para valores TTL de 16 a 64, culparía al firewall.
Todo esto esperfectamente normal. No proporciona ninguna evidencia de que haya un problema.
Como usted no proporciona los datos de ping, no podemos saber si hay congestión en la red.
Podrías encontrarmtr https://github.com/traviscross/mtrte da una mejor idea.