¡Primera pregunta! ¡Hola!
Ejecutándose en Ubuntu 16.04.
Información de hardware: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
Me enfrento a algunos bloqueos extraños de Ethernet cuando ejecuto una aplicación P2P -> más precisamente:https://github.com/prysmaticlabs/prysm. Según los mismos registros de la aplicación, alrededor de 30 pares están conectados a mi máquina. La utilización del ancho de banda ha sido baja (picos de 6 Mbps), estoy utilizando un cable Cat6 y obtuve alrededor de 120 Mbps de enlace ascendente de fibra y los puertos se reenviaron correctamente según lo informado porpuedes vermeorg. Otras aplicaciones P2P, como torrents, no muestran ningún comportamiento conflictivo.
Como ya se ha dicho, los síntomas son extraños. Cuando ejecuto la aplicación, no parece perder conectividad. Pero en el momento en que otra aplicación necesita ejecutarse en la red (por ejemplo, navegación web, chat, transferencia de archivos), la interfaz se detiene durante segundos o incluso minutos. Me di cuenta de esto porque la navegación se agotaba con frecuencia.
Cuando se producen bloqueos, la aplicación sigue ejecutándose normalmente, pero todas las demás aplicaciones pierden la conexión a Internet. Superviso el tráfico ICMP (ping):
- Del host al enrutador
- De otro anfitrión local al anfitrión estancado
En ambos dispositivos, deja de devolver cualquier tipo de respuesta (el terminal detiene la salida, no hay retroalimentación y no hay tiempos de espera). Después de una larga pausa, de repente, se reconocen todos los paquetes. Vea este ejemplo:
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
Luego la red vuelve a la normalidad, por un tiempo.
Cosas que he probado:
- Incrementando MTU de 1500 a 9000 (sin efecto)
- Aumentando txqueuelen de 1000 a 11000 (sin efecto)
- Limitar el número de pares que pueden conectarse (sin efecto)
- Virtualización (sin efecto)
- Eliminando el reenvío de puertos. Esto parece funcionar, aunque supera el propósito de la aplicación y la hace considerablemente más lenta.
En este punto tengo dos teorías:
1) O la puerta de enlace está actuando de forma extraña (no se puede comprobar). Descarto esto porque otros dispositivos en la red funcionan bien, tanto en conexiones locales como en conexiones externas 2) O algún tipo de búfer de memoria se está ahogando, pero no sé cuál.
¡Agradecería la inspiración!
Respuesta1
Para esa tarjeta, podrías intentar arrancar con este parámetro del kernel.Esto explica cómo hacerlo.:
pcie_aspm=off
Otra forma es usar ethtool. Por ejemplo:
sudo ethtool -G eth0 rx 256 tx 256
eso viene deaquí.
Respuesta2
Después de una mayor depuración de todos los elementos de la red, descubrí que aunque los efectos en otros dispositivos son mucho menos notorios, de hecho están siendo afectados por el atasco, por lo que esto me lleva a pensar que el problema está en el enrutador/conmutador. Lo cual probablemente sea asfixiante para cumplir con la demanda de la aplicación P2P, tal vez debido a las traducciones NAT. Intentaré conseguir hardware más avanzado para solucionar este problema.