Quais são algumas técnicas para rastrear a(s) causa(s) raiz(ões) de atrasos intermitentes, às vezes muito longos, nas sessões do TigerVNC?
Trabalhando remotamente via SSH usando TigerVNC. Na maioria das vezes a tela responde. No entanto, muitas vezes ao dia, há atrasos na resposta; estes podem variar de meio segundo a váriosminutos, com caracteres digitados e movimentos do mouse e ações permanecendo em buffer. Isso é muito perturbador quando ocorre no meio da escrita de uma linha de código.
Durante esses atrasos, os pings ocorrem (até agora) sem problemas e outros acessos à Internet funcionam bem.
Estamos na ComCast com um plano de desempenho relativamente alto. O WiFi não é um problema, pois meu laptop está conectado por meio de um switch ao nosso roteador/modem a cabo. A empresa para a qual trabalho está em um ISP diferente. A TI diz que outras pessoas com ComCast tiveram problemas semelhantes, mas não há outras opções de ISP disponíveis atualmente onde moro.
Um traceroute (ligeiramente redigido) ...pausasno Hop 9, e shows * * *para esse 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 * * *
Até agora, uma ligação para o suporte técnico da Comcast produziu um número de tíquete de suporte, uma tentativa talvez reflexiva de me fazer trocar nosso modem a cabo (relativamente novo) e (até o momento) nenhuma chamada de retorno. No entanto, o problema não é a velocidade lenta durante a operação normal, e nossa conexão não cai (que eu saiba); pings e outros acessos à Internet continuam funcionando sem atrasos durante as pausas, e as teclas digitadas e as ações do mouse permanecem armazenadas em buffer.
Eu apreciaria qualquer ideia para:
- Como isolar o problema de software, problema de rede ou?
- Ferramentas para ajudar a isolar
- Neste último caso, como dizer ao nosso ISP o que está errado, na esperança de que isso chegue a alguém com acesso para consertar
- Como superar isso (possivelmente alugando um escritório onde outro ISP esteja disponível)
Editar: por sugestão de uso sudo journalctl -b 0 -u NetworkManager:
os registros mostram muitos trigêmeos de:
connectivity: (en01) timed out, imediatamente seguido por:manager: NetworkManager state is now CONNECTED_SITE,- Então, após um atraso de 4 minutos e 31 segundos (?) sempre:
manager: NetworkManager state is now CONNECTED_GLOBALsequências.
Exemplo, com o nome do sistema cortado:
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
Responder1
Os pacotes IP têm um campo Time-To-Live projetado para evitar que os pacotes fiquem em loop para sempre.
Todo roteador é obrigado a reduzir o campo TTL cada vez que o pacote é encaminhado.
Quando o TTL ficar abaixo de 1, o roteador deverá enviar de volta um pacote ICMP informando que o campo TTL expirou. Além disso, deve descartar o pacote.
traceroutefunciona enviando 3 pacotes com TTL 1 e escutando os pacotes ICMP. Ele informa o tempo necessário e a origem do relatório. Em seguida, ele envia 3 pacotes com TTK 2 e informa os hosts e os horários. O TTL de 3, depois um TTL de 4 e assim por diante. O programa, entretanto, não espera indefinidamente. Se você não obtiver uma resposta ICMP, ele imprimirá um arquivo *.
Portanto, para TTL de 9, nenhuma resposta ICMP é recebida. Isso pode ocorrer porque o roteador está configurado para não enviar respostas ou pode haver regras de firewall bloqueando os pacotes. A lentidão está apenas esperando pelas respostas.
Para valores TTL de 16 a 64 eu culparia um firewall.
Tudo isso éperfeitamente normal. Não fornece nenhuma evidência de que haja um problema.
Como você não fornece os dados de ping, não podemos saber se há congestionamento na rede.
Você pode encontrarmtr https://github.com/traviscross/mtrlhe dá uma visão melhor.