Batman-adv -> CPU bottleneck?

Nabend,

ich habe bei mir zuhause lange Zeit einen WDR3600 verwendet, der über MoL von meinem PC („Offloader“) das Freifunk-Netz bekommt, und dann Mesh- und Client-Netze aufmacht. Die Geschwindigkeit war damit aber immer sehr limitiert, ich habe Höchstgeschwindigkeiten von 30Mbps gesehen. Das ist ja schon gut, aber die Server haben mehr Luft nach oben.

Aktuell habe ich das Setup folgendermaßen verändert: Auf dem WDR3600 läuft kein Gluon mehr sondern ein LEDE ohne batman-adv. Der PC („Offloader“) bridged ein VLAN mit dem Freifunk-Netz und der WDR3600 strahlt dieses als „Semifreifunk“ aus. Hiermit ist die Performance mit ca. 100Mbps nahezu identisch der meines privaten WLAN.

Schliesse ich daraus richtig, dass das Bottleneck durch batman-adv auf dem WDR3600 entsteht? Oder hat das was mit schlechtem Airtime-Management durch das 802.11s-Netzwerk zu tun?

– Milan // PetaByteBoy

Den Eindruck habe ich zumindest.
Ich bekomme aus einem 4300er zum 78MBit/s per FF an einem 100MBit Unitymedia heraus, sofern ich das Wifimesh abschalte.

Hi

Muss der 3600 fragmentieren? Man könntest testweite mal den Link zwischen 3600er und den Offloader auf einen so hohen MTU stellen das Batman komplett durchpasst, dann muss der Offloader das fragmentieren übernehmen, was durchaus CPU kostet.

WLAN wäre auch denkar, Speedtests daher mal über Kabel machen nur da kannste es zuverlässig sagen.

mfg

Christian

Moin,

du schreibst nicht im Detail, ob du alle Messungen über WLAN gemacht hast? Es klingt fast so, aber du hast es nicht dazu geschrieben.

Optionen zum Testen:

  • WDR3600 über Kabel testen, also wieder Gluon drauf, LAN-Mesch aus und da mal per Kabel dran. Von den 841ern weiß ich, dass die über Kabel um die 60 Mbit/s mit L2TP schaffen, über Funk aber nur 30. Warum weiß irgendwie niemand so genau
  • Kernelversion. Auf welcher Kernelversion basiert dein Lede, auf welcher Gluon? Evtl. hat das LEDE schon diese Optimierungen mit der Reduzierung der Paketwarteschlange drin. Das soll den Nettodatendurchsatz steigern

Ich gehe aber primär einfach davon aus, dass die Pakete unter Gluon durch die CPU müssen(das ist ein Fakt, weil Batman und so) und das Gerät unter LEDE einfach nur als AP fungiert und die irgendwie hardwaremäßig direkt aus dem Kabel in die Luft gehen ohne durch die CPU zu müssen (das ist Theorie).

Grüße
Matthias

Da der 4300er (oder 3600er) eigntlich auch nur ein 1043er(v2) mit DualBand-Wifi ist:

1043v2 hat sich hier als Batman-Switch bewährt, um Batman-Linkstrecken zu separieren.
dort passen nach meiner Beobachtung problemlos 70MBit/s Paketleistung im Dauerstrich durch. Der Bottleneck liegt dann an irgendwelchen pPOE-Speisungen, die wegen falscher Netzteile nur auf 100MBit/s laufen…

Stimmt nicht so ganz, der TL WDR4900 V2 ist ein WR1043 V2 mit Dualband, die beiden anderen haben nicht so schnelle Prozessoren an Bord. Der WDR4900 V1 hat sogar ne 800MHz CPU.

und eine völlig andere Architektur hat also mit dem 1043 gar nichts gemein :wink:

worüber diskutiert ihr hier jetzt?
(Hint: Das Thema dieses Threads ist nicht, sich gegenseitig die Tabelleninhalte aus dem deviwiki unter die Nase zu reiben.)

Der Sprung 30MBit/s auf 78MBit/s ist wirklich nicht mit einem Unterschied von vielleicht 30% an CPU-Speed (sind beides 74c afaik) zu erklären.

Will sagen: Ich denke nicht, dass batman-adv hier den Flaschenhals darstellt. (Sicher gibt es den auch, aber vorher greifen hier andere Dinge.)

Folgende Beobachtung habe ich gemacht:

Ausgangslage:

  • Freifunk-Münsterland L2TP-Domäne
  • 1&1 VDSL 50/10-Anschluss mit FritzBox 7412, kein Limit für Freifunk
  • TL-1043ND v4 als Uplink
  • TL-WR940 v3 angebunden via Mesh-on-LAN
  • Traffic wurde erzeugt via SSH mittels wget {-4/-6} -O /dev/null http://speedtest.belwue.net/10G
  • Messung der genutzten Bandbreite via Auslastungsanzeige der FritzBox
  1. Ein wget-Prozess auf dem Uplink-Router (WR1043) mit Option -4, d.h. direkter Traffic an Freifunk vorbei. Datendurchsatz: 50 Mbit/s
  2. Wie (1.) aber mit Option -6, d.h. Traffic über Freifunk. Datendurchsatz: ca. 30 Mbit/s
  3. Wie (2.) aber mit zwei parallelen wget-Prozessen. Datendurchsatz: ca. 42 Mbit/s
  4. Wie (2.) aber mit drei parallelen Prozessen. Datendurchsatz knapp 50 Mbit/s, top meldet: 0% idle
  5. Wie (3.), zusätzlich ein wget-Prozess auf dem WR940. Ergebnis wie (4.)
  6. Ein wget-Prozess auf dem MoL-Router (WR940). Datendurchsatz ca. 10 Mbit/s
  7. Wie (6.) aber mit zehn wget-Prozessen auf dem WR940. Datendurchsatz ca. 30 Mbit/s
  8. Wie (6.) aber mit 20 wget-Prozessen auf dem WR940. Datendurchsatz ca. 42 Mbit/s
  9. Wie (6.) aber mit 30 wget-Prozessen auf dem WR940. Datendurchsatz 50 Mbit/s. top auf dem WR1043: 35 % idle, top auf dem WR940: 5 % idle
4 „Gefällt mir“

Da zeigt einfach meiner Interpretation nach einfach nur, dass TCP-Verbindungen extrem latenz- und verlustempfindlich sind. Und mehrere parallel Verbindungen können das ausgleichen.

D.h. allein die höhere Latenz der Verbindung vom MoL-Router via Uplink im Vergleich zur Verbindung vom Uplink direkt verursacht eine Verringerung von 30 Mbit/s auf 10 Mbit/s?

Dem sollte nicht so sein. An der BezReg haben wir ja ein ähnliches Problem, was wir nicht genau verstehen.

Das deckt sich übrigens auch mit unseren Beobachtungen.

Komischet weiße verschlechtert sich das Problem je größer die Batman Domäne ist.

Man muss dann immer mehr parallele DLs gegen werfen um das maximal mögliche aus dem Offloader zu bekommen.

In leeren Domänen geht das schon mit einem oder zwei Threads.

1 „Gefällt mir“

Jein.
Wenn Sender und Empfänger daran angepasst sind, das BandbreitenLatenzprodukt immer auf der Reise zu halten, so wird die Strecke optimal genutzt. Wenn die Latenz groesser wird, muss man den RecvBufferSize und damit auch die maximale RecvWindowgroesse vergroessern.
Im Worstcase ist zB RecvBuffer nur 1xMSS und jedes verdammte Frame wird quittiert. Also fleissiges Pingpong aber nix kommt rueber, weil die Kapazitaet der Strecke nicht genutzt wird. Wenn man aber zu viel reinstopft, produziert man uU selber Verluste. Daher adaptiert sich TCP, wenn Verluste auftreten.

Auf dem Knoten selbst zu testen, muss also nicht optimal sein und muss nicht eine typische Client Server situation repraesentieren. Idealerweise testet man also mit einer Client/Server Kombi, die man am besten einstellen kann, sodass man eine Idee bekommt, was geht.
Also am besten nativ Linux auf CLient/server.
Und dafuer reicht normalerweise eine DL Session. Wenn man Verluste hat, so wird man mit mehr Sessions wohl auch nur mehr Verluste erzielen. Da kommt netto wohl nicht mehr bei raus, naehme ich an.
Normalerweise braucht man mehr als eine Session nur dann, wenn man zB bei 10+Gbps Sessions an irgendwelche Systemflaschenhaelse stoesst, weil irgendwas nicht mehr skaliert (CPU oder interne Ressourcen).

Ich wuerde also mit normalen Linux Client/Servern testen und mit iperf Server/Clients und ihren Parametern spielen und die Knoten Knoten sein lassen. Dann kann man auch selber tracen und sich die Sessions ansehen.
Diese multiplen wget Versuche zeigen hoechstens, dass da schlecht angepasste TCP Sessions herauskommen. Normalerweise ist das ja auch ein unrealistisches Szenario, weil da keine Clientprozesse laufen sollten. Es ist nicht nachvollziehbar, wieso nicht ein wget eine zB 50mbit Strecke sättigen können sollte. Also sendet der Sender nicht genug, weil der Client nicht genug WIndowsize anbietet.
Leider hat der der busybox wget da keine Optionen.

Man muss sich wirklich die TCP Sessions genau ansehen, um die Ursachen erkennen zu koennen.

Die TCP-Mechanismen sind dafür gebaut Congestion zu erreichen. Mit „echten“ Paketverlusten, wie sie systembedingt im Freifunk recht häufig auftreten, rechnet der Algorithmus nicht. Daher sind mehrere Verbindungen besser als eine.