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
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.
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.
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.
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).