[Problem] 6490 mit OS7.00 schlechter WLAN durchsatz im lokalem Netz

[back2live]

ich suche jemanden der dieses Szenario mit testen kann.
Benötigt wird eine Fritzbox 6490 mit OS 7 ein eigener Router bzw. ein Layer3 Switch.

Getestet werden müsste der Datendurchsatz über das eingebaute WLAN der 6490 in ein anderes lokales Subnetz über den eigenen Router.

Seit der Version 7 ist der Durchsatz extrem eingebrochen, bei V6.xx war die Geschwindigkeit im Wlan mit einem Laptop bei gut 12MB/s. 2,4 oder 5GHz ist egal, beides ist betroffen.
Seit dem Update auf V7.0 ist dieser auf ca. 400k/s eingebrochen und somit nicht mehr nutzbar.
Die Verbindung über das WLAN direkt in das Internet ist jedoch weiterhin schnell.
Über einen Extra Accesspoint ist die Geschwindigkeit wieder normal schnell auch wenn dieser an der 6490 eingesteckt wird. Auch die Geschwindigkeit über die eingebauten Kupferports der 6490 ist auf 1Gbit Niveau.

vielleicht gibt es auch jemanden mit dem selben Problem.

 

[fesc]

Nochmal zum mitschreiben (?):

WLAN->Lokales netz (1G-port): Langsam? Ist es nur eine bestimmte Richtung die Probleme macht?
WLAN->Kabel: Normal?
WLAN->AP->1G-Port->Kabel: Normal?

Ein "Allheilmittel" soll ja angeblich das Abschalten der "Paktbeschleunigung" in support-interface sein (fritz.box/support.lua).

Das macht bei mir allerdings keinen Unterschied: in beide Richtungen bekomme ich immer 20-25 MB/sec (Wlan<->Lan<->router<->endpoint), scp Datenübertragung.

Edit: Auf dem lan habe ich einen OpenWRT router ..

 

[back2live]

WLAN->Lokales netz (1G-port): Langsam? Ist es nur eine bestimmte Richtung die Probleme macht?

Ja aber nur wenn es im lokalem LAN einen Router gibt mit einem anderen Subnetz
z.B. WLAN Endgerät 192.168.178.20 --> eigener Router: 192.168.178.100 --> weiteres Subnetz im LAN mit z.B. einer IP 192.168.123.123

Diese Verbindung wäre langsam
Dabei ist es egal ob das WLAN Gerät als Default Gateway die 192.168.178.100 oder die FB als Gateway verwendet. Bei FB als Gateway muss natürlich in der FB die Route eingetragen sein. 192.168.123.0 255.255.255.0 192.168.178.100

​

WLAN->Kabel: Normal?

Ja

​

WLAN->AP->1G-Port->Kabel: Normal?

eher so gemeint?
WLAN->AP+1G-Port->Kabel: Normal?
dann Ja​

Danke aber schon fürs Testen

 

[fesc]

(Der router hat aber nicht zufaellig die Adresse 192.168.178.254 (wie bei einem aehnlichen Fehlerbericht in einem anderen Forum)?)
Vergiss die Frage, das war eine andere FW Version..

Mal probiert den LAN port auf 100MBit zu schalten?

 

[back2live]

Dann würde ich die Kupferports der 6490 bremsen, die sind ja schnell auch dahin wo das WLAN langsam ist.

Auch die Geschwindigkeit über die eingebauten Kupferports der 6490 ist auf 1Gbit Niveau.

 

[fesc]

Es gibt Berichte wonach es mit GBit Probleme gibt, ich weiss aber nicht was da dran ist.
Has du auf dem Router mal geschaut ob auf den Schnittstellen Fehler gemeldet werden? Oder ob es viele TCP retransmits gibt?

 

[back2live]

Habe ich gerade getestet hilft auch nichts, keine Fehler auf den Kupferports. Ist auch klar da die Kupferverbindungen fehlerfrei und schnell sind.

Die 6490 hat einen eingebauten 1GBit Switch, mein Router ist mit einem Kabel an der 6490 angeschlossen --> 1GBit Link.
an einem weiteren Kupferport der 6490 ein Laptop. Die Verbindung ist in das andere Subnetz über meinen Router schnell ca. 100MB/s
Die gleiche Verbindung über das eingebaute WLAN der 6490 extrem langsam.

 

[fesc]

Seltsam .. was ich bisher gesehen habe hat sich mit 7.0 eher was in Richtung Kabel getan (z.B. was das queuing betrifft, hatte da mal ein Bildchen gemalt).

 

[back2live]

Danke für die tolle Aufzeichnung.

Kann sich bei OS7 im Bezug auf deine Zeichnung gröberes geändert haben?

Ich wüsste auch nicht wie man wenn man es wollte so ein Problem künstlich erzeugen könnte.

Etwas anderes was mir noch bei OS7 aufgefallen ist:
Man streamt ein DVB-C HD Programm und kopiert gleichzeitig über den internen Switch der 6490 mit 1GBit Daten dann hat der DVB-C Stream Aussetzer, das ist mir bei 6.87 auch noch nie passiert.

 

[fesc]

Kann sich bei OS7 im Bezug auf deine Zeichnung gröberes geändert haben

Ein paar Kleinigkeiten sind mir bis jetzt aufgefallen, z.B. das in Richtung Kabel keine qdisc regeln mehr vergeben sind (war bei 6.8x wohl ein workaround gegen bufferbloat).
Aber auf der reinen LAN/WLAN/Switching-Seite hat sich nach jetzigem Erkenntnisstand nix gravierendes getan (ich habe aber noch nicht so genau geforscht).

Laufen die Daten denn auch ueber WLAN, oder nur zwischen zwei switchports? Es ist eigentlich so dass dieser so intelligent eingestellt ist dass die Pakete nicht ueber die (software)-lan1 bridge laufen.
Sollte dem jetzt doch so sein (was ich mir kaum vorstellen kann, dann wuerde ja alle 4 1Gb ports ueber eine einzige 1Gb RGMII schnittstelle laufen) ist dass natuerlich eine CPU-Last fuer den Atom, was wiederum Auswirkungen auf den DVB-C daemon (cableinfo) haben koennte (der ist recht sensitiv was CPU last betrifft).

Werde ich mal messen bei Gelegenheit.

 

[fesc]

Ich habe das ganze nochmal getestet, und kann es teilweise nachvollziehen.
Zum test habe ich zwei Linux rechner an zwei verschiedenen ports. Als test laeuft iperf3.

Normalerweise stabil mit knapp 1GBit/sec, wie zu erwarten (nur die gelegentlichen retransmits sollten nicht sein):
[ 4] 298.00-299.00 sec 107 MBytes 895 Mbits/sec 0 465 KBytes
[ 4] 299.00-300.00 sec 106 MBytes 890 Mbits/sec 1 375 KBytes
[ 4] 300.00-301.00 sec 100 MBytes 842 Mbits/sec 7 390 KBytes

Lasse ich diesen iperf3 test laufen waehren die Box bootet passiert komisches.
Unmittelbar nach dem Start der box ist der Durchsatz wie zu erwarten bei knapp 1GBit/sec, faellt dann steil ab und pendelt sich bei 500MBis/sec ein:
[ 4] 280.00-281.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
[ 4] 281.00-282.00 sec 12.2 MBytes 103 Mbits/sec 207 209 KBytes
[ 4] 282.00-283.00 sec 106 MBytes 889 Mbits/sec 0 342 KBytes
(ca. 10sec)
[ 4] 291.00-292.00 sec 106 MBytes 888 Mbits/sec 0 362 KBytes
[ 4] 292.00-293.00 sec 105 MBytes 883 Mbits/sec 0 365 KBytes
[ 4] 293.00-294.00 sec 104 MBytes 870 Mbits/sec 0 373 KBytes
[ 4] 294.00-295.00 sec 41.5 MBytes 349 Mbits/sec 247 280 KBytes
[ 4] 295.00-296.00 sec 19.2 MBytes 161 Mbits/sec 0 327 KBytes
(ca. 10sec)
[ 4] 312.00-313.00 sec 22.8 MBytes 191 Mbits/sec 0 1.38 MBytes
[ 4] 313.00-314.00 sec 24.7 MBytes 207 Mbits/sec 0 1.64 MBytes
[ 4] 314.00-315.00 sec 28.8 MBytes 241 Mbits/sec 0 1.96 MBytes
[ 4] 315.00-316.00 sec 32.1 MBytes 269 Mbits/sec 0 2.31 MBytes
[ 4] 316.00-317.00 sec 38.5 MBytes 323 Mbits/sec 0 2.72 MBytes
[ 4] 317.00-318.00 sec 44.2 MBytes 371 Mbits/sec 0 2.94 MBytes
[ 4] 318.00-319.00 sec 45.8 MBytes 384 Mbits/sec 0 2.94 MBytes
[ 4] 319.00-320.00 sec 44.0 MBytes 369 Mbits/sec 0 2.94 MBytes
[ 4] 320.00-321.00 sec 48.2 MBytes 404 Mbits/sec 0 2.94 MBytes
Pendelt sich bei ca. 500MBit ein.

Mit abschalten der Paketbeschleunigung im support-dialog geht die Performance dann ganz in den Keller. Die TCP window size ist sehr klein, es kommt oft zu retransmits:
[ 4] 39.00-40.00 sec 26.7 MBytes 224 Mbits/sec 0 1.91 MBytes
[ 4] 40.00-41.00 sec 23.9 MBytes 200 Mbits/sec 195 714 KBytes
[ 4] 41.00-42.00 sec 20.0 MBytes 168 Mbits/sec 0 771 KBytes
[ 4] 42.00-43.00 sec 21.7 MBytes 182 Mbits/sec 0 812 KBytes
[ 4] 43.00-44.00 sec 21.2 MBytes 178 Mbits/sec 0 836 KBytes

Auch ein reaktivieren hilft dann nichts mehr, mehr als 500MBit ist nicht mehr drin.

Wer dieses Problem also hat sollte mal probieren beim booten der box keinen traffic zu erzeugen (ports abklemmen?).

Die Ursache liegt m.E. irgenwo beim Konfigurieren des externen switches. Der muss ja halbwegs intelligent sein da er poert-zu-port-traffic ja nicht an den Atom schicken soll, und die anderen mit einem port-tag versehen. Ich nehme an hier setzt auch die "Paketbeschleunigung" an.
Man sieht das auch an den Paketcountern fuer eth0-3 bzw. vlan_master0: Die sind bei hohem Durchsatz viel geringer als wenn das Problem da ist oder die Paketbeschleunigung aus.

(In einer alten firmware-Version konnte ich direkt auf die register des switches per MDIO zugreifen, das geht jetzt leider nicht mehr (so einfach).)

Edit: Ist evtl etwas off-topic bzgl. des Thread-titels, aber vielleicht verwandt ..

 

[back2live]

Ok, das schaue auch schon etwas seltsam aus, super das du auch etwas gesucht hast.
Das könnte tatsächlich der gleiche Ursprung des Problems sein wie ich es mit dem WLAN habe.

Vielleicht könntest du aus einem Linux Rechner einen Router machen den anderen dann dahinter in einem anderen Subnetz und auf diesen dann per WLAN verbinden dann wäre es auch noch ein guter Test.

 

[fesc]

Das mit einem router hatte ich schon einmal probiert (s.o.).

Es wird noch komischer: Nachdem mein Test 1/2 tag gut lief war er auf einmal wieder bei <=500MBit/sec.
Habe dann einen der beiden Rechner auf WLAN umgestellt -> 12mbit/sec (kann leider nur 2.4Ghz ..). Also wieder das LAN-Kabel eingesteckt und schon war er wieder auf 900MBit/sec.

Ich denke da gibt es irgendein Problem beim learning/aging im externen switch, evtl. werde ich mein "athtool" doch portieren.

In diesem Zustand ist die 6490 eigentlich unbrauchbar als switch. Die Frage ist ob es beid einer aktuelleren 6590 firmware genauso ist .. d.h. ob es sich lohnt auf 7.02 fuer 6490 zu warten oder weiter selbst debuggen.

 

[fesc]

So jetzt:
Man kann auf der box gut den traffic und die Konfiguration des externen switches einsehen (/proc/driver/avmnet/ar8327).

Was man sieht ist dass sich die box im Fehlerfall "weigert" Eintraege fuer bestimmte hosts in die L2 table des switches vorzunahmen (das ist unter software-kontrolle, d.h. der switch lernt nicht automatisch).
Das fuehrt dann dazu dass die einkommenden Pakete auf port A fuer den (nicht gelernten) host an port B an den CPU port, d.h. an den atom-core geschickt werden (sieht man gut am paketcounter fuer den CPU port, der normalerweise nix tut wenn nur port-zu-port traffic stattfindet).
Der Atom muss dann den job des switches uebernehmen und ist damit wohl ziemlich ueberfordert, d.h. die Performance geht in den Keller. Normalerweise muss er das wohl nur fuer die ersten paar Pakete machen, dann die L2 tabelle des switches aktualiseren, und hat dann Ruhe.
In meinem Fall war das so dass der traffic von iperf direkt von port A zu B ging, die ACKs von B zu A aber ueber den Atom.

Im Prinzip ist das so aehnlich wie die "Puma 6 DOS attacke", wo der traffic durch den ARM core geroutet wird wenn man die lookup-tabellen zum Ueberlauf bringt.

Was genau dazu fuerhrt dass Eintraege nicht gelernt werden weiss ich nicht. Auch wie sich diese Situation recovert: manchmal half abklemmen des ports, manchmal bei iperf einfach das umdrehen der Richtung.

Und warum das alles so kompliziert sein muss verstehe ich gar nicht. Frueher (ich glaube bis FW 6.6) war der switch "flach" (ohne VLANs, bis auf "port 1" Betrieb) und hat selber lernen duerfen.

Vielleicht finde ich noch einen workaround, aber es heisst wohl einfach abwarten bis AVM das fixt (weiss jemand ob das bei 6590 auch auftritt??).

.. und ob das jetzt nochwas mit dem ursprunglichen Problem zu tun hat weiss ich auch nicht, denn die WLAN Daten gehen ja einen ganz anderen Weg (eigentlich immer ueber den Atom). Aber man koennte ja mal schauen wie die L2 Eintraege aussehen (cat /proc/driver/avmnet/ar8327/acl, wenn man einen login hat).

 

[timse1895]

Hallo zusammen,

ich "darf" auf meiner [email protected] auch die geschilderte Problematik beobachten.

SystemA --(LAN-Port@1Gbit)--> 6490 --(WiFi)--> WiFi-Bridge[TP-Link Archer C7 v2] --(LAN-Port@1Gbit)--> Switch --(LAN-Port@1Gbit)--> SystemB

Alle Systeme befinden sich in einem Subnet.

Allerdings ist kein gesondertes Netz notwendig um dieses Verhalten zu reproduzieren, als Ursache konnte ich bei mir statische Routen@6490 ausmachen.
Sobald auch nur eine Route zusätzlich eingetragen ist(es kann auch eine fiktive Route sein), tritt das Durchsatzproblem(A(LAN)->B(WiFi) ~400kb/s) auf.

Es beschränkt sich bei mir allerdings auf den Weg von SystemA --> SystemB (siehe oben), der Rückweg (B -> A) ist ohne Einschränkungen.
Wie auch bei @back2live ist an SystemB ins Internet der volle Speed vorhanden (UM@400/20).

Bei meinen Tests hatte die "Paketbeschleunigung" übrigens keine Auswirkungen auf die Performance (wenn keine Route gesetzt an/aus; wenn Route gesetzt an/aus).

Grüße!

 

[fesc]

Interessant. Mit was hast Du getestet?
Die eingehenden Pakete am LAN port der 6490 muessen von dieser ja gelernt werden, d.h. in die L2 tabelle des internen switches gespeichert weren. Da dies wohl unter software-kontrolle passiert hat die box damit etwas Arbeit. Wenn das nun nicht klappt, dann haette die box bei jedem Paket diese Arbeit, was erklaeren wuerde warum der traffic A->B langsamer ist als B->A (im letzteren Fall muesste sich die "lernsoftware" nur noch um die ACKs kuemmern muessen).

Beim Weg WiFi-Internet ist der switch nicht involviert. Bleibt noch die Frage was das mit einer Route zu tun haben soll (die habe ich nicht).

 

[timse1895]

Oh Schande über mein Haupt, da war ich zu schnell mit meiner "Schlussfolgerung".

Die Problematik ist im Rahmen der Tests sehr zeitnah nach dem Eintragen der Route aufgetreten, sodass ich die Annahme hatte, dass es damit zusammenhängt.

Dein Hinweis auf die L2-Tabelle lässt mich aufhorchen, da bei mir durch die Verwendung der Wifi-Bridge ja alle Geräte "hinter" der Bridge über eine MAC adressiert werden.
Und wenn dieser Vorgang (wie in #14 beschrieben) schief läuft, erklärt es das Verhalten.

Nun läuft die 6490 seit ein paar Stunden mit aktiver Route und das Problem tritt nicht auf.
Habe jetzt die Box neugestartet und das Problem/Verhalten tritt direkt wieder auf, jedoch hat es sich dann nach wenigen Paketen erübrigt, da das "learning" dann diesmal funktioniert hat.

 

[back2live]

@fesc

danke auf di Idee bin ich noch gar nicht gekommen das es an der MAC Tabelle im Switch liegen könnte, das macht aber auf jeden fall sinn. da alle IPs hinter dem Router ja die selbe MAC haben, schaut wirklich so aus als würde der Switch da Mist bauen. bzw. mit der Seite mit dem WLAN welches ja mittlerweile dann scheinbar über ein internes VLAN kommt ein Problem haben.

 

[fesc]

Ich habe mal wieder etwas Zeit investiert ...

Ich habe mein tool zum switch konfigurieren auf den atom portiert, damit kann ich den switch jetzt so umkonfigurieren dass alle ports in einem VLAN sind. Fuer die box sieht es so aus als ob alles an einem port haengt.
AVM macht es uebrigens so dass sie fuer jede port-zu-port Kommunikation eine ACL Regel im switch eintragen (bzw. zwei fuer hin und zurueck) damit die pakete zwischen den ports-vlans direkt geschickt werden. Die eigentliche L2/ARL tabelle ist damit praktisch unbenutzt. Das habe ich wieder aktiviert.

Ob/welche Probleme es loest kann ich nicht sagen, wer es probieren will muss "leider" meine FW modifikation und das application package installieren .. ein script um den switch "flach" zu machen ist in:
packages/x86/athtool/flatten

Fuer das tool: athtool -h

Bisher laeuft es stabil, ohne "Verlangsamung", aber das will nix heissen, dachte ich schon einmal ..

 

[jebeyer]

Die Frage ist ob es beid einer aktuelleren 6590 firmware genauso ist .. d.h. ob es sich lohnt auf 7.02 fuer 6490 zu warten oder weiter selbst debuggen.

Offenbar ja und nicht nur bei mir, zumindest ist das Problem sehr ähnlich gelagert. Allerdings tritt es offenbar, wie auch bei der 6490 mit 7.00, auch nicht bei jedem 6590-Besitzer auf. Und es trat bei mir auch schon in den Mesh-Labors für 6590 auf. Seitdem stehe ich mit AVM deswegen in Kontakt. Und seit 7.00 für 6590 ist auch ein Ticket von mir bei AVM eröffnet.
Mit 7.01 (ist jetzt für die 6590 verfügbar) muss ich das erst noch ausführlich testen.
Und ein "Allheilmittel" ist das Abschalten der (HW-) Paketbeschleunigung natürlich nicht. Und soll lt. AVM (auf meine nochmalige Nachfrage) auch nur als temp. Workaround benutzt werden. Und hilft ja offensichtlich nicht bei jeder Konfiguration (bei mir schon). Bei mir genügt es auch, die Paketbeschleunigung einmal komplett zu deaktivieren und dann gleich wieder zu aktivieren- ohne Neustart. An einer Lösung arbeitet man bei AVM wohl immer noch.
seihe auch hier: https://www.ip-phone-forum.de/threa...-00-vom-28-08-2018.300662/page-3#post-2298856
Das ist allerdings nur die Kurzbeschreibung meines Problems.