Erste Frage! Hallo!
Läuft unter Ubuntu 16.04.
Hardwareinfo: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
Beim Ausführen einer P2P-Anwendung treten bei mir seltsame Ethernet-Stalls auf -> genauer gesagt:https://github.com/prysmaticlabs/prysm. Laut den gleichen Anwendungsprotokollen sind etwa 30 Peers mit meinem Rechner verbunden. Die Bandbreitenauslastung war gering (Spitzen von 6 Mbit/s), ich verwende ein Cat6-Kabel und habe etwa 120 Mbit/s Glasfaser-Uplink und die Ports wurden korrekt weitergeleitet, wie vonkannst du mich sehenorg. Andere P2P-Apps, wie etwa Torrents, zeigen keine widersprüchlichen Verhaltensweisen.
Wie gesagt, die Symptome sind seltsam. Wenn ich die Anwendung ausführe, scheint die Verbindung nicht verloren zu gehen. Aber sobald eine andere Anwendung im Netzwerk ausgeführt werden muss (z. B. Surfen im Internet, Chatten, Dateiübertragung), bleibt die Schnittstelle für Sekunden oder sogar Minuten hängen. Das ist mir aufgefallen, weil beim Surfen häufig eine Zeitüberschreitung auftrat.
Wenn es zu Unterbrechungen kommt, läuft die Anwendung normal weiter, aber alle anderen Anwendungen verlieren die Internetverbindung. Ich überwache den ICMP-Verkehr (Ping):
- Vom Host zum Router
- Von einem anderen lokalen Host zum stagnierenden Host
Auf beiden Geräten wird keine Antwort mehr zurückgegeben (Terminal stoppt die Ausgabe, kein Feedback und keine Timeouts). Nach dem langen Stillstand werden plötzlich alle Pakete bestätigt. Sehen Sie sich dieses Beispiel an:
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
Dann kehrt das Netzwerk für eine Weile zum Normalzustand zurück.
Dinge, die ich versucht habe:
- Erhöhung der MTU von 1500 auf 9000 (keine Auswirkung)
- Erhöhung von txqueuelen von 1000 auf 11000 (keine Auswirkung)
- Begrenzung der Anzahl der Peers, die eine Verbindung herstellen können (keine Auswirkung)
- Virtualisierung (keine Auswirkung)
- Portweiterleitung entfernen. Das scheint zu funktionieren, verfehlt allerdings den Zweck der App und macht sie deutlich langsamer.
An diesem Punkt habe ich zwei Theorien:
1) Entweder verhält sich das Gateway merkwürdig (kann nicht überprüft werden). Ich schließe das aus, da andere Geräte im Netzwerk sowohl bei lokalen als auch bei externen Verbindungen einwandfrei laufen. 2) Oder eine Art Speicherpuffer ist verstopft, aber ich weiß nicht, was davon der Fall ist.
Ich freue mich über Inspiration!
Antwort1
Antwort2
Nach eingehenderer Fehlersuche an allen Elementen im Netzwerk habe ich festgestellt, dass die Auswirkungen auf andere Geräte zwar viel weniger spürbar sind, diese aber tatsächlich vom Datenstau betroffen sind. Dies lässt mich vermuten, dass das Problem beim Router/Switch liegt, der wahrscheinlich nicht mit der Nachfrage der P2P-Anwendung Schritt halten kann, möglicherweise aufgrund von NAT-Übersetzungen. Ich werde versuchen, fortschrittlichere Hardware zu besorgen, um dieses Problem zu lösen.