Первый вопрос! Привет!
Работает на Ubuntu 16.04.
Информация об оборудовании:lspci | awk '/[Nn]et/ {print $1}' | xargs -i% lspci -ks %
00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (2) I219-V
Subsystem: ASUSTeK Computer Inc. Ethernet Connection (2) I219-V
Kernel driver in use: e1000e
Kernel modules: e1000e
02:00.0 Network controller: Intel Corporation Device 093c (rev 3a)
Subsystem: Intel Corporation Device 7001
Я сталкиваюсь со странными зависаниями Ethernet при запуске P2P-приложения -> точнее:https://github.com/prysmaticlabs/prysm. Согласно тем же журналам приложений, к моей машине подключено около 30 пиров. Использование полосы пропускания было низким (пики 6 Мбит/с), я работаю на кабеле Cat6 и получил около 120 Мбит/с оптоволоконного восходящего канала, а порты были правильно перенаправлены, как сообщаетТы видишь меняorg. Другие P2P-приложения, такие как торренты, не демонстрируют никакого конфликтного поведения.
Как уже говорилось, симптомы странные. Когда я запускаю приложение, оно, похоже, не теряет соединение. Но в тот момент, когда другое приложение должно работать в сети (например, просмотр веб-страниц, чат, передача файлов), интерфейс останавливается на секунды или даже минуты. Я заметил это, потому что просмотр часто прерывался по тайм-ауту.
Когда происходят сбои, приложение продолжает работать нормально, но все остальные приложения теряют подключение к интернету. Я отслеживаю трафик ICMP (ping):
- От хоста к маршрутизатору
- От другого локального хоста к зависшему хосту
В обоих устройствах он прекращает возвращать какой-либо ответ (терминал прекращает вывод, нет обратной связи и нет тайм-аутов). После долгого простоя внезапно все пакеты подтверждаются. Смотрите этот пример:
64 bytes from 192.168.1.1: icmp_seq=1122 ttl=64 time=0.304 ms
64 bytes from 192.168.1.1: icmp_seq=1123 ttl=64 time=0.303 ms
64 bytes from 192.168.1.1: icmp_seq=1124 ttl=64 time=0.313 ms
64 bytes from 192.168.1.1: icmp_seq=1125 ttl=64 time=0.263 ms
64 bytes from 192.168.1.1: icmp_seq=1126 ttl=64 time=0.266 ms
64 bytes from 192.168.1.1: icmp_seq=1127 ttl=64 time=0.273 ms
64 bytes from 192.168.1.1: icmp_seq=1128 ttl=64 time=0.289 ms
64 bytes from 192.168.1.1: icmp_seq=1129 ttl=64 time=0.276 ms
64 bytes from 192.168.1.1: icmp_seq=1130 ttl=64 time=0.280 ms
64 bytes from 192.168.1.1: icmp_seq=1131 ttl=64 time=0.635 ms
64 bytes from 192.168.1.1: icmp_seq=1132 ttl=64 time=0.292 ms
64 bytes from 192.168.1.1: icmp_seq=1133 ttl=64 time=0.537 ms
64 bytes from 192.168.1.1: icmp_seq=1134 ttl=64 time=0.299 ms
64 bytes from 192.168.1.1: icmp_seq=1135 ttl=64 time=0.272 ms
64 bytes from 192.168.1.1: icmp_seq=1136 ttl=64 time=27625 ms
64 bytes from 192.168.1.1: icmp_seq=1137 ttl=64 time=26635 ms
64 bytes from 192.168.1.1: icmp_seq=1138 ttl=64 time=25631 ms
64 bytes from 192.168.1.1: icmp_seq=1139 ttl=64 time=24640 ms
64 bytes from 192.168.1.1: icmp_seq=1140 ttl=64 time=23641 ms
64 bytes from 192.168.1.1: icmp_seq=1141 ttl=64 time=22671 ms
64 bytes from 192.168.1.1: icmp_seq=1142 ttl=64 time=21648 ms
64 bytes from 192.168.1.1: icmp_seq=1143 ttl=64 time=20652 ms
64 bytes from 192.168.1.1: icmp_seq=1144 ttl=64 time=19658 ms
64 bytes from 192.168.1.1: icmp_seq=1145 ttl=64 time=18655 ms
64 bytes from 192.168.1.1: icmp_seq=1146 ttl=64 time=17658 ms
64 bytes from 192.168.1.1: icmp_seq=1147 ttl=64 time=16659 ms
64 bytes from 192.168.1.1: icmp_seq=1148 ttl=64 time=15655 ms
64 bytes from 192.168.1.1: icmp_seq=1149 ttl=64 time=14632 ms
64 bytes from 192.168.1.1: icmp_seq=1150 ttl=64 time=13611 ms
64 bytes from 192.168.1.1: icmp_seq=1151 ttl=64 time=12588 ms
64 bytes from 192.168.1.1: icmp_seq=1152 ttl=64 time=11565 ms
64 bytes from 192.168.1.1: icmp_seq=1153 ttl=64 time=10542 ms
64 bytes from 192.168.1.1: icmp_seq=1154 ttl=64 time=9522 ms
64 bytes from 192.168.1.1: icmp_seq=1155 ttl=64 time=8501 ms
64 bytes from 192.168.1.1: icmp_seq=1156 ttl=64 time=7478 ms
64 bytes from 192.168.1.1: icmp_seq=1157 ttl=64 time=6459 ms
64 bytes from 192.168.1.1: icmp_seq=1158 ttl=64 time=5436 ms
64 bytes from 192.168.1.1: icmp_seq=1159 ttl=64 time=4415 ms
64 bytes from 192.168.1.1: icmp_seq=1160 ttl=64 time=3391 ms
64 bytes from 192.168.1.1: icmp_seq=1161 ttl=64 time=2370 ms
64 bytes from 192.168.1.1: icmp_seq=1162 ttl=64 time=1350 ms
64 bytes from 192.168.1.1: icmp_seq=1163 ttl=64 time=320 ms
64 bytes from 192.168.1.1: icmp_seq=1164 ttl=64 time=2.73 ms
64 bytes from 192.168.1.1: icmp_seq=1165 ttl=64 time=0.258 ms
64 bytes from 192.168.1.1: icmp_seq=1166 ttl=64 time=0.303 ms
Затем сеть на некоторое время возвращается в нормальное состояние.
Что я пробовал:
- Увеличение MTU с 1500 до 9000 (без эффекта)
- Увеличение txqueuelen с 1000 до 11000 (без эффекта)
- Ограничение количества подключаемых одноранговых узлов (без эффекта)
- Виртуализация (без эффекта)
- Удаление переадресации портов. Кажется, это работает, хотя это противоречит цели приложения и делает его значительно медленнее.
На данный момент у меня есть две теории:
1) Либо шлюз ведет себя странно (не могу проверить). Я отбрасываю это, поскольку другие устройства в сети работают нормально, как в локальных соединениях, так и в внешних соединениях. 2) Либо какой-то буфер памяти забивается, но какой именно — не знаю.
Буду признателен за вдохновение!
решение1
Для этой карты вы можете попробовать загрузиться с этим параметром ядра.Здесь объясняется, как это сделать.:
pcie_aspm=off
Другой способ — использовать ethtool. Например:
sudo ethtool -G eth0 rx 256 tx 256
Это происходит изздесь.
решение2
После дополнительной отладки всех элементов сети я обнаружил, что хотя эффекты в других устройствах гораздо менее заметны, они действительно страдают от пробки, поэтому это заставляет меня думать, что проблема кроется в маршрутизаторе/коммутаторе, который, вероятно, задыхается, чтобы удовлетворить спрос приложения P2P, возможно, из-за трансляций NAT. Я попытаюсь получить более продвинутое оборудование, чтобы решить эту проблему.