Mastodon

Performancemessung zugschlus-ka51 (Freifunk Knoten als VM)

Technik
#1

Hallo,

ich habe seit Inbetriebnahme meines Freifunk-Knotens zugschlus-k51 schon das Gefühl, dass der nicht so performt wie ich es gerne hätte. Und eben habe ich mal ein wenig gemessen. Hier meine Ergebnisse:

Infrastruktur:

  • Freifunk-Knoten als VM auf meinem “kleinen” Virtualisator in der Laborumgebung bei mir im Keller
  • Anbindung DSL 100/40
  • Zwischen dem Freifunk-Knoten und dem DSL hängt noch eine Linux-Firewall
  • Freifunk-Knoten ist meines Wissens auf 15 Mbit/s beschränkt (wie prüfe ich das?)
  • Performance beim Download aus dem VLAN zwischen Knoten und Accesspoints jedoch < 2 Mbit/s, auch wenn der Client mit Kabel am Ethernet hängt
  • IPv6 als Tunnelträger ist abgeschaltet, da mein IPv6 nur getunnelt ist.
  • Es ist verifiziert, dass der Freifunk-Knoten auch nur über IPv4 mit Eurer Infrastruktur spricht

Beim debugging habe ich mich an Wie führe ich Speedtests für Freifunk durch? orientiert.

Laut https://map.ffrn.de/#!v:m;n:52540025ab54 ist die IP-Adresse meines Knotens 2a01:4f8:171:fcff:5054:ff:fe25:ab54; laut http://2a01:4f8:171:fcff:5054:ff:fe25:ab54/ ist er mit gw06.ffrn.de verbunden.

Messungen direkt auf der Knoten-VM:

Messungen mit einem über Ethernet in das VLAN zwischen Knoten und Accesspoints eingekoppelten Notebook:

Any Ideas?

Grüße
Marc

#2

Von dieser Beschränkung wüsste ich nix. Meistens ist hier die Hardware der limitierende Faktor, da unser VPN meines Wissens im User Space läuft. Du kannst das aber im config mode oder über ssh überprüfen.

Ich tu jetzt mal ein bisschen kompetent, aber die Frage wird kommen: mit was virtualisierst du denn? Ich hab hier mitbekommen, dass es doch ziemlich unterschiede bei den Virtualiserungslösungen gibt. @tobox hat sich da schon mal vor ner Zeit mit beschäftigt wenn ich mich nich irre.

#3

Da steht simple-tc.mesh_vpn.limit_egress auf 1600 und limit-ingress auf 15000. Ich ging aber auch immer davon aus, das würde nur dann zuschlagen, wenn man mehrere Accessopints über die Luftschnittstelle meshen lässt.

Und wie erreiche ich den Config-Mode

Ich virtualisiere mit KVM unter Debian Linux. Meine Firewall läuft auf derselben Hardware und transportiert ohne mit der Wimper zu zucken mehrere hundert Megabit sustained. Die Netzwerkkarten sind virtio, Speicher hat die Möhre mehr als genug, und die i7 CPU steht auch nicht wirklich unter Strom. Und, wenn ich am Freifunk-VPN vorbei teste, bekomme ich ja auch > 50 Mbit/s. Wähernd der iperf-Tests über das VPN bleibt die CPU-Last auch unterhalb der Meßschwelle, die liegt beim Test über gw06.ffrn.de (also “außenrum”) deutlich höher.

#4

Ich fasse das mal für mich zusammen, da mir das gerade etwas unübersichtlich ist.

  • Deine Performance, direkt ohne VPN, zu unseren Gateways liegt bei etwa 50Mbit/s
  • Du hast ein Limit von 15Mbit/1,6Mbit (Up/Down) gesetzt
  • Die Performance die du per Kabel (quasi) am Offloader misst liegt bei etwa 5Mbit/s im Download.

Das sollte nicht so.

Der ist bei solchen Offloadern etwas fummelig, aber du hast es ja scheinbar auch per SSH gefunden.

Nein das gilt für alle Daten die über das VPN gehen. Also alle Clients und alles was per Mesh dran hängt.

Was die Virtualisierung angeht, ich glaube da gab es irgendwas zu beachten aber das weiß @NurticVibe genauer als ich.

#5

Ich hatte bei einem simplen Test auf einer alten Möhre mal 35 MBit gemessen: Offloader in VMware/QEMU/Virtualbox

Schalte mal die Bandbreitenbegrenzung ab, ich habe irgendwo im Hinterkopf dass die deutlich Performance kosten kann.

#6

Wie mach ich das denn? Auf welchen Wert muss ich die Variablen setzen um die Begrenzung wegzumachen?

#7

https://wiki.freifunk.net/Konsole#Bandbreitenbegrenzung_.C3.A4ndern

#8

Hast Du auch auf die zweite Frage eine Antwort? Ein absurd hoher Wert oder gibt es da einen speziellen Wert der den ganze Begrenzungs-Code lahmlegt?

#9

uci set simple-tc.mesh_vpn.enabled=‘0’

#10

Ok, Messung folgt morgen. Bin grad im Dezernat 16 und habe Rechner auf dem Tisch auf denen der Freifunk gar nicht geht.

#11

Auch mit dieser Einstellung wird das Ergebnis von iperf nach intern.gw06.ffrn.de nicht besser.

Grüße
Marc

#12

Ich nehme an, Du hast geschaut, dass die Einstellung gespeichert wurde und danach neu gestartet?

Geben die üblichen Verdächtigen (top etc) irgendwelche Hinweise?

#13

Mir war weder bewusst, dass man die Einstellungen, die man mit uci set gemacht hat, speichern muss, noch dass sie erst nach einem Neustart wirksam werden.

Speichern wäre “uci commit”?

top innerhalb des offloaders habe ich nicht probiert, atop wird es da keins geben.

Außerhalb des Offloaders zeigt atop auf dem Virtualisator nicht, dass es irgendwelche außergewöhnlichen Lastsituationen gibt; der Offloader selbst kann mit realistischer Performance ins Netz (siehe die Messungen ohne das VPN), andere VMs auf derselben Hardware auch.

Grüße
Marc

#14

Ja, das ist dann also “uci set”, “uci commit” und “reboot”.

Ich habe jetzt herausgefunden, dass es zwar einen Zusammenhang zwischen der bei limit_ingress eingestelllten Datenrate und der tatsächlich gemessenen Datenrate gibt, dieser Zusammenhang aber weder numerisch stimmt noch es einen linearen Zusammenhang gibt. Setze ich beide Limits auf 200000, gehen etwa 40 Mbit durch; setze ich sie auf 100000, sind wir knapp unter 30 Mbit.

Nach einigen Versuchen bin ich jetzt bei 50000 für beide Werte gelandet, das sind dann für den Endnutzer so zwischen 15 und 18 Mbit, damit kann ich leben. Jetzt möchte ich eigentlich noch den Upstream begrenzen, denn die eingestellten 50000 sind mehr als ich physikalisch Upstream habe, aber jede weitere Reduktion des limit_egress nimmt die für den Endnutzer sichtbare Datenrate sofort wieder spürbar ab.

Damit funktioniert das jetzt immerhin gut genug, dass ich es so lassen werde und es nicht noch mit den Lösungen von anderen Freifunk-Vereinen probieren muss (zu denen ich persönlich bessere Kontakte habe als zu Euch).

Danke für alle HIlfsversuche.

Grüße
Marc