Каковы некоторые методы отслеживания основных причин периодических, иногда очень длительных задержек в сеансах TigerVNC?
Работа удаленно через SSH с помощью TigerVNC. Большую часть времени экран реагирует. Однако, много раз в день, есть задержки в ответе; они могут составлять от половины секунды до несколькихминут, с набранными символами и движением мыши и действиями, остающимися в буфере. Это очень мешает, когда это происходит в середине написания строки кода.
Во время этих задержек пинги проходят (пока) без каких-либо проблем, и другой доступ в Интернет работает нормально.
Мы пользуемся ComCast с относительно высокопроизводительным планом. С WiFi проблем нет, так как мой ноутбук подключен через коммутатор к нашему маршрутизатору/кабельному модему. Компания, в которой я работаю, пользуется услугами другого интернет-провайдера. ИТ-отдел сообщает, что у других пользователей ComCast были похожие проблемы, однако в настоящее время там, где я живу, других интернет-провайдеров нет.
Трассировка маршрута (слегка отредактированная)...паузына 9-м перелете и шоу * * *для этого перелета.
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 * * *
Звонок в техподдержку Comcast пока дал номер тикета поддержки, возможно, рефлекторную попытку заставить меня сменить наш (довольно новый) кабельный модем и (пока) никакого обратного звонка. Однако проблема не в низкой скорости при нормальной работе, и наше соединение (насколько мне известно) не обрывается; пинги и другой доступ в Интернет продолжают работать без задержек во время пауз, а нажатия клавиш и действия мыши остаются буферизованными.
Буду признателен за любые идеи по следующим вопросам:
- Как определить, связана ли проблема с программным обеспечением, сетевым подключением или...?
- Инструменты, помогающие изолировать
- Если последнее, как сообщить нашему интернет-провайдеру, что не так, в надежде, что эта информация дойдет до кого-то, у кого есть доступ, чтобы исправить это?
- Как это обойти (возможно, просто арендовать офис, где доступен другой интернет-провайдер)
Редактировать: по предложению использовать sudo journalctl -b 0 -u NetworkManager:
в журналах показано множество триплетов:
connectivity: (en01) timed out, сразу же за которым следует:manager: NetworkManager state is now CONNECTED_SITE,- Затем после задержки в 4 минуты 31 секунду(?) каждый раз:
manager: NetworkManager state is now CONNECTED_GLOBALпоследовательности.
Пример с обрезанным именем системы:
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
решение1
IP-пакеты имеют поле времени жизни, предназначенное для предотвращения бесконечного зацикливания пакетов.
Каждый маршрутизатор должен уменьшать поле TTL каждый раз при пересылке пакета.
Когда TTL становится ниже 1, маршрутизатор должен отправить обратно пакет ICMP, сообщающий, что поле TTL истекло. Кроме того, он должен отбросить пакет.
tracerouteработает, отправляя 3 пакета с TTL 1 и прослушивая пакеты ICMP. Он сообщает требуемое время и откуда пришел отчет. Затем он отправляет 3 пакета с TTK 2 и сообщает хосты и время. TTL 3, затем TTL 4 и так далее. Однако программа не ждет бесконечно. Если ur не получает ответ ICMP, он печатает *.
Так что для TTL 9 не приходят ответы ICMP. Это может быть связано с тем, что маршрутизатор настроен не отправлять ответы, или могут быть правила брандмауэра, блокирующие пакеты. Медлительность заключается только в ожидании ответов.
При значениях TTL от 16 до 64 я бы обвинил брандмауэр.
Все это естьсовершенно нормально. Это не дает никаких доказательств того, что проблема существует.
Поскольку вы не предоставляете данные ping, мы не можем определить, есть ли перегрузка в сети.
Вы можете найтиmtr https://github.com/traviscross/mtrдает вам лучшее представление.