이더넷 인터페이스가 ~30초 동안 응답을 중지한 다음 수신된 모든 패키지를 승인하는 이유는 무엇입니까?

이더넷 인터페이스가 ~30초 동안 응답을 중지한 다음 수신된 모든 패키지를 승인하는 이유는 무엇입니까?

첫 번째 질문! 안녕!

우분투 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

P2P 애플리케이션을 실행할 때 이상한 이더넷 정지 현상이 발생합니다. 더 정확하게는 다음과 같습니다.https://github.com/prysmaticlabs/prysm. 동일한 애플리케이션 로그에 따르면 약 30개의 피어가 내 컴퓨터에 연결되어 있습니다. 대역폭 활용도가 낮습니다(최고 6Mbps). 저는 Cat6 케이블을 사용하고 있으며 약 120Mbps의 파이버 업링크를 얻었으며 보고된 대로 포트가 올바르게 전달되었습니다.canyouseemeorg. 토렌트와 같은 다른 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

네트워크의 모든 요소를 ​​더 많이 디버깅한 후 다른 장치의 영향은 훨씬 눈에 띄지 않지만 실제로 트래픽 정체의 영향을 받고 있다는 사실을 발견했습니다. 따라서 문제가 라우터/스위치에 있다고 생각하게 되었습니다. 아마도 NAT 변환 때문에 P2P 애플리케이션의 요구를 충족하기가 어려울 것입니다. 이 문제를 해결하기 위해 더 발전된 하드웨어를 얻으려고 노력할 것입니다.

관련 정보