Welche Techniken gibt es, um die Grundursache(n) für zeitweilige, manchmal sehr lange Verzögerungen in TigerVNC-Sitzungen aufzuspüren?
Remote-Arbeit über SSH mit TigerVNC. Meistens reagiert der Bildschirm. Allerdings kommt es mehrmals am Tag zu Verzögerungen bei der Reaktion; diese können von einer halben Sekunde bis zu mehreren Sekunden reichen.Protokoll, wobei eingegebene Zeichen sowie Mausbewegungen und Aktionen gepuffert bleiben. Dies ist sehr störend, wenn es mitten beim Schreiben einer Codezeile geschieht.
Während dieser Verzögerungen werden Pings (bisher) ohne Probleme durchgestellt und andere Internetzugriffe funktionieren einwandfrei.
Wir haben einen relativ leistungsstarken Tarif bei ComCast. WLAN ist kein Problem, da mein Laptop über einen Switch mit unserem Router/Kabelmodem fest verkabelt ist. Die Firma, für die ich arbeite, hat einen anderen ISP. Die IT sagt, dass andere mit ComCast ähnliche Probleme hatten, aber an meinem Wohnort gibt es derzeit keine anderen ISP-Optionen.
Ein Traceroute (leicht redigiert) …Pausenbei Hop 9 und Shows * * *für diesen Hop.
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 * * *
Ein Anruf beim technischen Support von Comcast hat bisher eine Support-Ticketnummer ergeben, einen vielleicht reflexartigen Versuch, mich dazu zu bringen, unser (ziemlich neues) Kabelmodem auszutauschen, und (bis heute) keinen Rückruf. Das Problem ist jedoch nicht die langsame Geschwindigkeit während des normalen Betriebs, und unsere Verbindung bricht (soweit ich weiß) nicht ab; Pings und andere Internetzugriffe funktionieren während der Pausen weiterhin ohne Verzögerungen, und Tastenanschläge und Mausaktionen bleiben gepuffert.
Ich freue mich über jede Idee zu:
- Wie kann das Problem auf die Software, ein Netzwerkproblem usw. eingegrenzt werden?
- Werkzeuge zur Isolierung
- Wenn letzteres der Fall ist, wie können wir unserem ISP mitteilen, was falsch ist, in der Hoffnung, dass dies an jemanden durchsickert, der den Zugriff hat, um das Problem zu beheben?
- Wie Sie das umgehen können (möglicherweise einfach ein Büro mieten, in dem ein anderer ISP verfügbar ist)
Bearbeiten: pro Verwendungsvorschlag sudo journalctl -b 0 -u NetworkManager:
Protokolle zeigen viele Drillinge von:
connectivity: (en01) timed out, unmittelbar gefolgt von:manager: NetworkManager state is now CONNECTED_SITE,- Dann jedes Mal nach einer Verzögerung von 4 Minuten und 31 Sekunden(?):
manager: NetworkManager state is now CONNECTED_GLOBALSequenzen.
Beispiel mit gekürztem Systemnamen:
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
Antwort1
IP-Pakete verfügen über ein Time-To-Live-Feld, das eine endlose Paketschleife verhindern soll.
Jeder Router muss das TTL-Feld bei jeder Paketweiterleitung reduzieren.
Wenn der TTL-Wert unter 1 fällt, sollte der Router ein ICMP-Paket zurücksenden, das besagt, dass das TTL-Feld abgelaufen ist. Außerdem muss er das Paket verwerfen.
traceroutefunktioniert, indem 3 Pakete mit TTL 1 gesendet und auf die ICMP-Pakete gewartet werden. Es meldet die benötigte Zeit und woher der Bericht kam. Dann sendet es 3 Pakete mit TTK 2 und meldet die Hosts und Zeiten. Dann ein TTL von 3, dann ein TTL von 4 und so weiter. Das Programm wartet jedoch nicht unbegrenzt. Wenn Sie keine ICMP-Antwort erhalten, wird ein *. ausgegeben.
Bei einem TTL von 9 werden also keine ICMP-Antworten empfangen. Dies kann daran liegen, dass der Router so konfiguriert ist, dass er keine Antworten sendet, oder dass Firewall-Regeln die Pakete blockieren. Die Verlangsamung entsteht einfach dadurch, dass auf die Antworten gewartet wird.
Bei TTL-Werten von 16 bis 64 würde ich die Schuld einer Firewall geben.
All dies istvollkommen normalEs liefert keinen Beweis dafür, dass ein Problem besteht.
Da Sie die Ping-Daten nicht angeben, können wir nicht feststellen, ob im Netzwerk eine Überlastung vorliegt.
Vielleicht finden Siemtr https://github.com/traviscross/mtrgibt Ihnen einen besseren Einblick.