Warum werden meine drahtlosen Verbindungen (Mac oder PC) für einige Sekunden regelmäßig stark beeinträchtigt?

338
Hubro

Ich habe gerade einen neuen Router gekauft, der ziemlich teuer war ( ASUS RT-AC66U ). Ich stellte schnell fest, dass drahtlose Verbindungen über 2,4 GHz und 5 GHz ziemlich schlecht waren. Die Ergebnisse sind auf einem Mac oder einem PC ähnlich. Eine typische Ping-Sitzung sieht folgendermaßen aus (über 2 Minuten, Intervall 1 Sekunde):

PING 192.168.1.1 (192.168.1.1): 56 data bytes 64 bytes from 192.168.1.1: icmp_seq=0 ttl=64 time=2.190 ms 64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=3.985 ms 64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=4.155 ms 64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=1.375 ms 64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=1.541 ms 64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=8.862 ms 64 bytes from 192.168.1.1: icmp_seq=6 ttl=64 time=12.327 ms 64 bytes from 192.168.1.1: icmp_seq=7 ttl=64 time=13.154 ms 64 bytes from 192.168.1.1: icmp_seq=8 ttl=64 time=4.244 ms 64 bytes from 192.168.1.1: icmp_seq=9 ttl=64 time=284.630 ms 64 bytes from 192.168.1.1: icmp_seq=10 ttl=64 time=301.342 ms 64 bytes from 192.168.1.1: icmp_seq=11 ttl=64 time=328.569 ms 64 bytes from 192.168.1.1: icmp_seq=12 ttl=64 time=10.168 ms 64 bytes from 192.168.1.1: icmp_seq=13 ttl=64 time=4.230 ms 64 bytes from 192.168.1.1: icmp_seq=14 ttl=64 time=1.207 ms 64 bytes from 192.168.1.1: icmp_seq=15 ttl=64 time=19.310 ms 64 bytes from 192.168.1.1: icmp_seq=16 ttl=64 time=4.040 ms 64 bytes from 192.168.1.1: icmp_seq=17 ttl=64 time=4.059 ms 64 bytes from 192.168.1.1: icmp_seq=18 ttl=64 time=4.233 ms 64 bytes from 192.168.1.1: icmp_seq=19 ttl=64 time=1.642 ms 64 bytes from 192.168.1.1: icmp_seq=20 ttl=64 time=1.593 ms 64 bytes from 192.168.1.1: icmp_seq=21 ttl=64 time=4.049 ms 64 bytes from 192.168.1.1: icmp_seq=22 ttl=64 time=4.223 ms 64 bytes from 192.168.1.1: icmp_seq=23 ttl=64 time=4.136 ms 64 bytes from 192.168.1.1: icmp_seq=24 ttl=64 time=1.277 ms 64 bytes from 192.168.1.1: icmp_seq=25 ttl=64 time=3.088 ms 64 bytes from 192.168.1.1: icmp_seq=26 ttl=64 time=4.268 ms 64 bytes from 192.168.1.1: icmp_seq=27 ttl=64 time=13.463 ms 64 bytes from 192.168.1.1: icmp_seq=28 ttl=64 time=4.167 ms 64 bytes from 192.168.1.1: icmp_seq=29 ttl=64 time=3.606 ms 64 bytes from 192.168.1.1: icmp_seq=30 ttl=64 time=2.931 ms 64 bytes from 192.168.1.1: icmp_seq=31 ttl=64 time=4.184 ms 64 bytes from 192.168.1.1: icmp_seq=32 ttl=64 time=4.071 ms 64 bytes from 192.168.1.1: icmp_seq=33 ttl=64 time=201.332 ms 64 bytes from 192.168.1.1: icmp_seq=34 ttl=64 time=218.367 ms 64 bytes from 192.168.1.1: icmp_seq=35 ttl=64 time=247.544 ms 64 bytes from 192.168.1.1: icmp_seq=36 ttl=64 time=57.321 ms 64 bytes from 192.168.1.1: icmp_seq=37 ttl=64 time=13.694 ms 64 bytes from 192.168.1.1: icmp_seq=38 ttl=64 time=3.918 ms 64 bytes from 192.168.1.1: icmp_seq=39 ttl=64 time=2.748 ms 64 bytes from 192.168.1.1: icmp_seq=40 ttl=64 time=1.839 ms 64 bytes from 192.168.1.1: icmp_seq=41 ttl=64 time=4.141 ms 64 bytes from 192.168.1.1: icmp_seq=42 ttl=64 time=3.919 ms 64 bytes from 192.168.1.1: icmp_seq=43 ttl=64 time=4.114 ms 64 bytes from 192.168.1.1: icmp_seq=44 ttl=64 time=1.316 ms 64 bytes from 192.168.1.1: icmp_seq=45 ttl=64 time=2.634 ms 64 bytes from 192.168.1.1: icmp_seq=46 ttl=64 time=10.943 ms 64 bytes from 192.168.1.1: icmp_seq=47 ttl=64 time=144.553 ms 64 bytes from 192.168.1.1: icmp_seq=48 ttl=64 time=158.767 ms 64 bytes from 192.168.1.1: icmp_seq=49 ttl=64 time=865.861 ms 64 bytes from 192.168.1.1: icmp_seq=50 ttl=64 time=1.009 ms 64 bytes from 192.168.1.1: icmp_seq=51 ttl=64 time=1.281 ms 64 bytes from 192.168.1.1: icmp_seq=52 ttl=64 time=1.199 ms 64 bytes from 192.168.1.1: icmp_seq=53 ttl=64 time=4.212 ms 64 bytes from 192.168.1.1: icmp_seq=54 ttl=64 time=1.714 ms 64 bytes from 192.168.1.1: icmp_seq=55 ttl=64 time=4.053 ms 64 bytes from 192.168.1.1: icmp_seq=56 ttl=64 time=21.046 ms 64 bytes from 192.168.1.1: icmp_seq=57 ttl=64 time=13.619 ms 64 bytes from 192.168.1.1: icmp_seq=58 ttl=64 time=14.630 ms 64 bytes from 192.168.1.1: icmp_seq=59 ttl=64 time=3.883 ms 64 bytes from 192.168.1.1: icmp_seq=60 ttl=64 time=4.119 ms 64 bytes from 192.168.1.1: icmp_seq=61 ttl=64 time=1.196 ms 64 bytes from 192.168.1.1: icmp_seq=62 ttl=64 time=4.048 ms 64 bytes from 192.168.1.1: icmp_seq=63 ttl=64 time=1.028 ms 64 bytes from 192.168.1.1: icmp_seq=64 ttl=64 time=1.116 ms 64 bytes from 192.168.1.1: icmp_seq=65 ttl=64 time=4.039 ms 64 bytes from 192.168.1.1: icmp_seq=66 ttl=64 time=16.272 ms 64 bytes from 192.168.1.1: icmp_seq=67 ttl=64 time=9.359 ms 64 bytes from 192.168.1.1: icmp_seq=68 ttl=64 time=29.070 ms 64 bytes from 192.168.1.1: icmp_seq=69 ttl=64 time=1.125 ms 64 bytes from 192.168.1.1: icmp_seq=70 ttl=64 time=3.871 ms 64 bytes from 192.168.1.1: icmp_seq=71 ttl=64 time=110.853 ms 64 bytes from 192.168.1.1: icmp_seq=72 ttl=64 time=131.584 ms 64 bytes from 192.168.1.1: icmp_seq=73 ttl=64 time=154.010 ms 64 bytes from 192.168.1.1: icmp_seq=74 ttl=64 time=1.178 ms 64 bytes from 192.168.1.1: icmp_seq=75 ttl=64 time=4.243 ms 64 bytes from 192.168.1.1: icmp_seq=76 ttl=64 time=9.988 ms 64 bytes from 192.168.1.1: icmp_seq=77 ttl=64 time=5.705 ms 64 bytes from 192.168.1.1: icmp_seq=78 ttl=64 time=19.701 ms 64 bytes from 192.168.1.1: icmp_seq=79 ttl=64 time=18.000 ms 64 bytes from 192.168.1.1: icmp_seq=80 ttl=64 time=3.954 ms 64 bytes from 192.168.1.1: icmp_seq=81 ttl=64 time=4.209 ms 64 bytes from 192.168.1.1: icmp_seq=82 ttl=64 time=1.173 ms 64 bytes from 192.168.1.1: icmp_seq=83 ttl=64 time=4.098 ms 64 bytes from 192.168.1.1: icmp_seq=84 ttl=64 time=3.956 ms 64 bytes from 192.168.1.1: icmp_seq=85 ttl=64 time=4.100 ms 64 bytes from 192.168.1.1: icmp_seq=86 ttl=64 time=16.471 ms 64 bytes from 192.168.1.1: icmp_seq=87 ttl=64 time=1.033 ms 64 bytes from 192.168.1.1: icmp_seq=88 ttl=64 time=4.681 ms 64 bytes from 192.168.1.1: icmp_seq=89 ttl=64 time=3.924 ms 64 bytes from 192.168.1.1: icmp_seq=90 ttl=64 time=4.040 ms 64 bytes from 192.168.1.1: icmp_seq=91 ttl=64 time=1.603 ms 64 bytes from 192.168.1.1: icmp_seq=92 ttl=64 time=1.626 ms 64 bytes from 192.168.1.1: icmp_seq=93 ttl=64 time=4.064 ms 64 bytes from 192.168.1.1: icmp_seq=94 ttl=64 time=3.708 ms 64 bytes from 192.168.1.1: icmp_seq=95 ttl=64 time=46.434 ms Request timeout for icmp_seq 96 64 bytes from 192.168.1.1: icmp_seq=96 ttl=64 time=1104.146 ms 64 bytes from 192.168.1.1: icmp_seq=97 ttl=64 time=794.081 ms 64 bytes from 192.168.1.1: icmp_seq=98 ttl=64 time=1.135 ms 64 bytes from 192.168.1.1: icmp_seq=99 ttl=64 time=3.810 ms 64 bytes from 192.168.1.1: icmp_seq=100 ttl=64 time=3.683 ms 64 bytes from 192.168.1.1: icmp_seq=101 ttl=64 time=4.350 ms 64 bytes from 192.168.1.1: icmp_seq=102 ttl=64 time=4.148 ms 64 bytes from 192.168.1.1: icmp_seq=103 ttl=64 time=3.907 ms 64 bytes from 192.168.1.1: icmp_seq=104 ttl=64 time=3.768 ms 64 bytes from 192.168.1.1: icmp_seq=105 ttl=64 time=1.644 ms 64 bytes from 192.168.1.1: icmp_seq=106 ttl=64 time=7.536 ms 64 bytes from 192.168.1.1: icmp_seq=107 ttl=64 time=7.881 ms 64 bytes from 192.168.1.1: icmp_seq=108 ttl=64 time=3.987 ms 64 bytes from 192.168.1.1: icmp_seq=109 ttl=64 time=1.364 ms 64 bytes from 192.168.1.1: icmp_seq=110 ttl=64 time=1.251 ms 64 bytes from 192.168.1.1: icmp_seq=111 ttl=64 time=1.632 ms 64 bytes from 192.168.1.1: icmp_seq=112 ttl=64 time=4.191 ms 64 bytes from 192.168.1.1: icmp_seq=113 ttl=64 time=4.285 ms 64 bytes from 192.168.1.1: icmp_seq=114 ttl=64 time=3.966 ms 64 bytes from 192.168.1.1: icmp_seq=115 ttl=64 time=1.419 ms 64 bytes from 192.168.1.1: icmp_seq=116 ttl=64 time=108.544 ms 64 bytes from 192.168.1.1: icmp_seq=117 ttl=64 time=52.418 ms 64 bytes from 192.168.1.1: icmp_seq=118 ttl=64 time=3.854 ms 64 bytes from 192.168.1.1: icmp_seq=119 ttl=64 time=486.287 ms  --- 192.168.1.1 ping statistics --- 120 packets transmitted, 120 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 1.009/52.774/1104.146/159.580 ms 

Etwa alle 10 bis 20 Sekunden nimmt die Verbindung schrecklich ab. Die Ping-Zeiten können über 1000 ms liegen (und es kommt häufig zu Paketverlusten), und die Bandbreite reicht von über 70 MB / s bis zu einigen hundert KB / s oder manchmal sogar 0 (getestet mit iperf3 mit TCP und UDP). .

Ich habe alles versucht. Ich habe versucht, den 5-GHz-Zugriffspunkt auf "Nur 802.11ac" und den 2,4-GHz-Zugriffspunkt auf "Nur 802.11n" einzustellen. Ich habe jeden Kanal und jede Kanalbreite für beide Zugangspunkte ausprobiert. Ich habe versucht, die Authentifizierung zu deaktivieren. Ich habe versucht, die neueste Firmware zu installieren und DD-WRT zu installieren. Nichts machte einen Unterschied.

Es kam mir vor, dass es möglicherweise Störungen von außen sein könnte. Ich habe versucht, mein MacBook mit aktiviertem WLAN-Hotspot an mein Telefon anzuschließen. Die Verbindung wurde wie bei der Verbindung zum Router regelmäßig abgebaut. Ich habe auch versucht, eine Verbindung zum drahtlosen Gerät (2,4 GHz) meines Nachbarn herzustellen (mit deren Erlaubnis natürlich), und dasselbe passiert dort.

Ich habe dies auch mit dem Windows-PC meines Bruders bestätigt, daher liegt es nicht an meinem MacBook. Aus gutem Grund habe ich auch versucht, alles in meiner Wohnung herunterzufahren, einschließlich meines eigenen Routers, meines Fernsehers, meines kabellosen Headsets und aller PCs. Ich zog auch den Stecker an meiner Mikrowelle und meinem Fernseher. Es machte keinen Unterschied.

Hat jemand eine Idee, was los sein könnte? Es scheint nicht wichtig zu sein, mit welchem ​​Gerät eine Verbindung zu einem anderen Gerät hergestellt wird. Welche Haushaltsgeräte könnten dies verursachen? Was kann ich tun, um das herauszufinden?

1
Können Sie lokalisierte Störungen ausschließen, indem Sie dieselbe Router- und Computer-Kombination an einem anderen Ort (vorzugsweise in weiter Entfernung) versuchen? Nate Barbettini vor 8 Jahren 0
Babyphone? Schnurloses Telefon Wi-Fi-Netzwerke der Nachbarn? DavidPostill vor 8 Jahren 1
Auch Mikrowellen und ähnliche Ausrüstungen ρss vor 8 Jahren 0
@DavidPostill Ich sehe einfach nicht, wie / warum ein Babyphon, ein schnurloses Telefon oder das WLAN eines Nachbarn alle 7-15 Sekunden alle Kanäle des 2,4-GHz- und des 5-GHz-Spektrums stören würde Hubro vor 8 Jahren 0
Ist 192.168.1.1 die Adresse des neuen RT-AC66U oder ist es die Adresse eines Upstream-Gateways? Wenn Sie über Ethernet an einen LAN-Port des RT-AC66U anschließen und dieselbe Adresse anpingen, tritt dasselbe Problem auf? Oh, hey, vielleicht war die Verlangsamung um 5 GHz ein anderes Problem. Schalten Sie die 2,4-GHz-Schnittstelle des RT-AC66U vollständig aus, sodass Interferenzen bei 2,4 GHz nicht mit Ihrem RT-AC66U verschraubt werden können und Sie nur beitreten 5 GHz und führen Sie den gleichen Ping-Test durch. Bekommen Sie dasselbe Ergebnis? Spiff vor 8 Jahren 0
Übrigens zeigt dieser Ping tatsächlich keinen Paketverlust, und Ping-Zeitschwankungen können durch den 802.11-Energiesparmodus verursacht werden (ohne auf tatsächliche Netzwerkprobleme hinzuweisen). Um zu verhindern, dass das Funkgerät in den 802.11-Energiesparmodus wechselt, müssen Sie mindestens einmal pro Beacon-Intervall einen Ping durchführen. Dies ist normalerweise eine Zehntelsekunde: `sudo ping -i 0,1 192.168.1.1`. Spiff vor 8 Jahren 0
@Spiff Ich habe versucht, 10 Mal pro Sekunde ein Ping-Signal auszuführen, [und das Problem bleibt bestehen] (http://pastebin.com/raw.php?i=F5VaXT71). Würde 802.11 auch mitten in einer Hochgeschwindigkeits-Dateiübertragung in den Energiesparmodus wechseln? Ich habe mit iperf3 getestet, 70 MB / s über 5 GHz mit UDP übertragen, und die Geschwindigkeit verlangsamt sich zu einem Zeitpunkt, zu dem die Ping-Spikes zu einem bestimmten Zeitpunkt kriechen. Das Problem tritt * nicht * auf, wenn es mit einem Kabel verbunden ist, es betrifft nur die drahtlosen Zugangspunkte. 192.168.1.1 ist die IP-Adresse des Asus-Routers. Ich habe auch schon versucht, einen Zugangspunkt zu deaktivieren, und es hat keinen Unterschied gemacht. Hubro vor 8 Jahren 0
@Spiff Ich habe jetzt 2,4 GHz deaktiviert und pinging mit 0,05s Intervallen: http://pastebin.com/raw.php?i=dW757mJW Hubro vor 8 Jahren 0
@Hubro Danke für die Updates. Ja, Ping-Latenzzeitspitzen, die auf Dateiübertragungsprobleme ausgerichtet sind, schließen den 802.11-Energiesparmodus aus. Es scheint, als hätten Sie alles außer RF-Interferenzen eliminiert, aber Interferenzen, die beide Bänder treffen, sind immer noch unwahrscheinlich. Es müsste ziemlich hoch sein, um beide Bands zu schlagen. Es sei denn, jemand hat einen fehlerhaften Wi-Fi-Scanner, der beide Marken spammt. Spiff vor 8 Jahren 0
Lassen Sie uns [diese Diskussion im Chat fortsetzen] (http://chat.stackexchange.com/rooms/29571/discussion-between-spiff-and-hubro). Spiff vor 8 Jahren 0
Wie Sie im Chat besprochen haben, sieht das nach einer weitreichenden Interferenz aus. Befinden Sie sich in der Nähe von Taxiunternehmen oder ähnlichem, die einen großen Sender bedienen können? Linef4ult vor 8 Jahren 0
@ Linef4ult Nicht das ich wüsste, aber was auch immer es ist, es verschlechtert immer noch WLAN-Verbindungen ~ 30 Meter von meinem Haus entfernt. Soweit habe ich bisher getestet. Hubro vor 8 Jahren 0
2,4 und 5 GHz sind nicht reguliert, ABER der Raum um sie herum ist in der Regel ein lizenziertes Spektrum. Vielleicht ist es an der Zeit, dies mit der Kommunikationsregulierungsbehörde Ihres Landes abzufragen. Linef4ult vor 8 Jahren 0

0 Antworten auf die Frage