Primeira pergunta! Oi!
Rodando no Ubuntu 16.04.
Informações 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
Estou enfrentando alguns travamentos estranhos de Ethernet ao executar um aplicativo P2P -> mais precisamente:https://github.com/prysmaticlabs/prysm. De acordo com os mesmos logs do aplicativo, cerca de 30 pares estão conectados à minha máquina. A utilização da largura de banda tem sido baixa (picos de 6 Mbps), estou executando um cabo Cat6 e obtive cerca de 120 Mbps de uplink de fibra e as portas foram encaminhadas corretamente conforme relatado porvocê consegue me verorganização. Outros aplicativos P2P, como torrents, não apresentam comportamentos conflitantes.
Como dito, os sintomas são estranhos. Quando executo o aplicativo, ele não parece perder a conectividade. Mas no momento em que outro aplicativo precisa ser executado na rede (por exemplo, navegação na web, bate-papo, transferência de arquivos), a interface para por segundos ou até minutos. Percebi isso porque a navegação expirava com frequência.
Quando ocorrem travamentos, o aplicativo continua funcionando normalmente, mas todos os outros aplicativos perdem a conexão com a Internet. Eu monitoro o tráfego ICMP (ping):
- Do host ao roteador
- De outro host local para o host em espera
Em ambos os dispositivos, ele para de retornar qualquer tipo de resposta (o terminal interrompe a saída, sem feedback e sem timeouts). Após a longa paralisação, de repente, todos os pacotes são reconhecidos. Veja este exemplo:
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
Então a rede volta ao normal, por um tempo.
Coisas que eu tentei:
- Aumentando o MTU de 1.500 para 9.000 (sem efeito)
- Aumentando txqueuelen de 1000 para 11000 (sem efeito)
- Limitando o número de peers que podem se conectar (sem efeito)
- Virtualização (sem efeito)
- Removendo o encaminhamento de porta. Isso parece funcionar, embora supere o propósito do aplicativo e o torne consideravelmente mais lento.
Neste ponto, tenho duas teorias:
1) O gateway está agindo de forma estranha (não é possível verificar). Descarto isso porque outros dispositivos da rede funcionam bem, tanto em conexões locais quanto em conexões externas 2) Ou algum tipo de buffer de memória está obstruído, mas não sei qual.
Eu apreciaria inspiração!
Responder1
Para essa placa você pode tentar inicializar com este parâmetro do kernel.Isso explica como fazer:
pcie_aspm=off
Outra maneira é usar ethtool. Por exemplo:
sudo ethtool -G eth0 rx 256 tx 256
Isso vem deaqui.
Responder2
Após mais depuração de todos os elementos da rede, descobri que embora os efeitos em outros dispositivos sejam muito menos perceptíveis, eles estão de fato sendo afetados pelo engarrafamento, o que me leva a pensar que o problema está no roteador/switch, o que provavelmente está sufocando para atender a demanda da aplicação P2P, talvez por causa das traduções do NAT. Vou tentar obter hardware mais avançado para resolver isso.