Der nächste Flaschenhals kommt dann übrigens… ChrisNo von Freifunk Straelen hat gestern seinen Offloader getestet und konnte über WLAN ca. 25mbit/s und über Kabel ca. 50mbit/s erreichen. Dabei hat sich die CPU des Offloader gelangweilt.
Wir vermuten den Flaschenhals beim physikalischen Interface des Host auf dem die ganzen Supernode-VMs laufen. Zu später Stunde hat er das aber nicht weiter durchleuchtet.
Yepp, dieses Offloading macht nur in Kombination mit dedizierten Gluon-Gateways Sinn; und da drückt dann der nächste Schuh. Wenn ‚nur‘ 100 MBit/sec Interfacebandbreite zur Verfügung stehen, sind das max. 12 841er á 8 MBit/sec oder max. 2 Offloader á 50 MBit/sec, wenn man die Geschwindigkeit ‚garantieren‘ will. Bei G.vector reduziert es sich auf 1:1.
Und da man fastd quasi nicht steuern kann, wird das Setup recht komplex …
Ich verweise nochmal gerne auf meine BananaPi Studie vom April.
Dort kann man auch den Unterschied von Verschlüsselung vs. Nullverschlüsselung sehen.
So wie ich das beurteilen kann reicht ein BananPi gerade zum VPN auslagern aus?
Kannst du mal ein image vom Pi ziehen und online stellen?
Würde mich auch interessieren
(KURZ)Anleitung Freifunk@Virtualbox
meine VBox-Anzeige weicht von Deiner ab,
Bei Adaptertyp hab ich keine Vorgabe, sondern Auswahl. Ich versuch mal mit Deiner Auswahl = Paravirtualsiertess Netzwerk
hab noch ein bei Dir nicht existierendes Feld Promiscuous-Modus, Vorgabe ist „deny“
aber bei X86-virtualbox.vdi image - #17 von biggesee ist „erlauben für alle VMs“
und bekomme Fehler
Nach Versuchen bekomme ich mit „Angeschlossen an Host-Only-Adapter“ und Adaptertyp Intel PRO 1000 einen funktionierenden Start der ersten Maschine. Argwöhne aber, daß das falsch ist.
Edit. Argwohn war treffend,
Problem lag in der fehlenden Netzwerkbrücke zwischen LAN zur Fritzbox und VBox Host-Only Netzwerk. Jetzt bekomme ich den Start der Maschine 1 mit „Netzwerkbrücke“ und „MAC Bridge Miniport“ (als einzige Möglichkeit)
aber wie gehts nun weiter ???
so weit ich verstanden habe, müsste ich nun 192.168.1.1 aufrufen bzw. anpingen können.
Ist aber nicht, ping gibt timeout, Browser sagt nicht gefunden.
Edit
habs zwar am Laufen, aber mit erschreckendem Ergebnis:
es funktioniert, aber terrible:
Testumgebung:
Fritzbox Port 2 Offloader
Fritzbox Port 3 ein 841
Speedtest (WLAN an 841)
down 1,03 - up 0,34 - ping 655
Edit
hab das nun isoliert gesetzt, und wenn ich https://freifunk-muensterland.de/wiki/doku.php?id=technik:virtualisiertes_gluon#virtualisiertes_gluon_konfigurieren => „Abschließend muss am Freifunkrouter ebenfalls Mesh-on-Wan aktiviert werden und Mesh-on-VPN deaktiviert werden.“ das auf den 841 mache und den offloader und das 841 per switch an port 2 der Fritzbox hänge, bekommt die 8451 zwar IPs und wird im Graphen mit Verbindung zu Wupper 1 + 2 gezeigt, aber ein Client bekommt kein Internet, und der offloader ist auch nicht im Graphen.
Also stimmt mit der Offloader-Konfiguration was nicht.
übrigens zum Vergleich der Werte oben: Wenn das 841 normal per WLAN mit dem 1043 (als normaler VPN) verbunden ist, bekommt ein Client per WLAN zum 841 15.88 down - 4.93 up - 27 ms
Kriegst du mehr Bandbreite, wenn du am WR841 VPN aktivierst?
Da sind wir jetzt bei einer Grundsatzfrage. Die Berliner verschlüsseln ihre Tunnel nicht. Aber das ist nicht Thema hier.
@Steneu Die Kölner auch nicht btw
@Pinky
testest du in einem Netzwerk mit einem weiteren entfernteren Uplink? Das würde die 2 MBit/s erklären, denn eigentlich solltest du gar kein Internet haben.
Du musst bei „Name“ etwas anderes als „VirtualBox Host-Only Adapter“ auswählen. Dann einen weiteren PC ans gleiche Netzwerk anschließen und feste IP 192.168.1.2 setzen und 192.168.1.1 ansurfen. Ich kann das genaue Setup mit VBox nicht testen, hab das Programm nicht. Der Screenshot von meinem letzten Post war aus den Weiten des Internetz.
KVM mit VirtIO und 20 Zeichen
Die 192.168.1.1 sollte sich direkt vom „Gastgeber-PC-der-VM“ erreichen lassen - war auf jeden Fall bei mir so…
es klappt (und natürlich war das nicht funktionierende Ping bereits das Zeichen beim ersten Versuch, dass was falsch war). Testoffloader ist nun auch im Graphen zu shen, und verbunden mit Wupper 1+2
Mit Beantworten meiner entsprechenden Fragen wären mir 4 Std Werkeln erspart geblieben. Danke.
Speed ist enttäuschend:
841 als VPN an Fritzbox Port 3 (100 Mbit/s) bring ca. 15.5 Mbit/s
841 ohne VPN an Fritzbox Port 3 via Offloader Port 2 (1 GBit/s) bringt ca. 10-14 Mbit/s, sehr stark schwankend
Allerdings, hab ich in VBox, wie hier empfohlen, Betriebssystem auf „unknown“ stehen und nur 1 CPU, wenngleich auch 2 GB RAM.
In Windows wird die Brücke mit 1GBit/s angezeigt.
Ich versuch mal andere Einstellungen. So, wie es jetzt ist, ist sinnlos.
Edit: wie änder ich dafür MTU?
Gar nicht. Ist wegen FastD Tunnel systembedingt. Einfach Ignorieren.
Nun hab ich ein schöneres Ergebnis, und das ist wirklich beeindrucken, wenn auch noch nicht das Ziel von 50 Mbit/s erreicht, aber ich bin auch noch nicht fertig:
Hab ein anderes Notebook genommen (HP 6830s, Win7/64, Intel Core2 Duo T5870 @ 2.00 GHz x 2, 6 GB RAM, SSD + HDD) dort geht , obwohl Win7/64 installiert, kein 64bit für VBox, nur 32 bit, Speicher für Machine auf 1GB (4GB gesamt wg. Win32-Auswahl), nur 1 CPU mit 2 Kernen, ausserdem MTU auf 1464 + 28 = 1492 gesetzt (ist bei meinem VDSL 50 - Netcologne - Anschluss anscheindend notwendig, Voreinstellung ist wg. LAN immer 1500 und das gibt fragmentierte Pakete.
Was nun die Verbesserung letztlich bewirkt hat, weis ich noch nicht, muss ich auf den besseren Notebook erst mal eine komplette Neuinstallation machen, damit beide echt vergleichbar sind.
Aber das Zwischenergebnis ist schon hübsch:.
[Fritzbox Port 3 via Offloader Port 2 (LAN 1 GBit/s) ] <=> LAN Fritzbox Port 3 100 Mbit/s <=> 841 <=> WLAN
28 - 31 Mbit/s
also 100% Verbesserung. während Speedtest-Download geht CPU-Load rauf auf 50-60%, sonst ist CPU bei 2-5%
nunja, 1532 MTU ist auch ein abenteuerlicher Wert 
Nö. BATMAN ist ein MESH Protokoll, und wie jedes zusätzliche Protokoll hat es einen Header. Dieser ist 32 Byte groß. Die normale LAN MTU ist 1500 Byte. Um die unfragmentiert zu übertragen muss also die MTU auf den Interfaces wo BATMAN-adv gesprochen wird z.B. auf der WLAN Seite um diese 32 Byte erweitert werden.
Steht auch so in der BATMAN-adv Doku:
Note: batman-adv inserts an additional header of 32 bytes into each data packet being send over the mesh. Therefore we are increasing the maximum size of a packet over the plain interfaces to 1532, so that packets with the standard MTU of 1500 can pass normaly through bat0.
standard MTU ist ja nur für LAN, schon bei den Providern, also für VPN-Kisten, ist das ja niedriger. Da die ja nicht mit 2 verschiedenen Paketgrössen arbeiten, müsste auch für WLAN das auf die niedrigeren Werte angepasst werden (können).
Oder seh ich was falsch?
Die MTU sollte immer 1500 sein, davon geht irgendwie jedes System aus. Usere Versuche, die MTU im FF-Netz (via DHCP- und RA-Option) auf irgendwas unter 1500 zu forcieren, waren ein großer Fehlschlag 
Mithin kommen GRE-Tunnel (FFRL) als Option für uns nicht mehr in Frage sigh (OpenVPN beherrscht die interne Fragmentierung, bietet also auf Wunsch einen 1500-Clear-Channel; das dußlige GRE nicht) …
Über meinen x86-KVM-Offloader komme ich auf gut 20 MBit/sec – mehr ist mit ca. 5 MBit/sec IPTV-Grundlast am 25er Entertain-Anschuß nicht drin. Und vor November darf ich von G.vector nur träumen (und auch das nur, weil ich so early adopted habe, daß ich VDSL, für, heute, Schweinepreise, indoor auch außerhalb des Nahbereichs um die Vst bekommen habe) …
Testergebnisse:
bester Wert down 38 MBit/s mit 841 an Offloader per WLAN an Notebook gemessen (mit LAN an erstem 841 gemessen => 43 MBit/s bei HP 6830s als Offloader)
Durschnittswert bei Offloader ->LAN-> 841 → WLAN => 841 (2 Räume weiter) 15-25 MBit/s, bester Wert 31 MBit/s
CPU load verhält sich analog Durchsatz, bis max 60% auf dem langsamen, bis max 30% auf dem schnelleren Notebook
für den Durchsatz macht es keinen Unterschied, welches Notebook, das schwächere ackert halt mehr, wenn es so viel überhaupt empfängt
für den Durchsatz macht es keinen Unterschied, ob direkt am Offloader ein 1043 oder ein 841 hängt. Mit dem 1043 wird nichts besser.
für den Durchsatz macht es keinen Unterschied, ob Offloader an 1 GBit (Port 1 oder 2) hängt, oder an 100 MBit/s (Port 3 oder 4)
Endkonstruktion:
Fitzbox Port 4 (GAST) 100 Mbit/s <=> 2m LAN bis Powerline <=> ca. 12m Leitung <=> Powerline <=> 1m LAN bis Swith (100Mbit/s) <=> 2m LAN an HP 6830s als Offloader <=> 1m LAN zu 1043 oder 841 (ist egal) <=> WLAN 841 (2 Räume + 2 Mauern weiter) <=> WLAN Notebook noch 2 Räume + 1 Mauer weiter
(just gerade jetzt) immer noch einen Download per WLAN von 19 Mbit/s, bei -45db Funksignal, ping 23 ms
Das 1043 oder 841 am Offlaoder geben durschschnittlich 25-30 Mbit/s
Als Offloader getestet:
HP 4720s Notebook - Intel Core i5 M480 @ 2,67 GHz x 2 (4 Kerne) - 8GB RAM - Win7/64 - mit VBox Setup ebenfalls Win7/64, 2 GB RAM - MTU 1464 + 28 = 1492 - Fritzbox VDSL 50
HP 6830s Notebook - Intel Core2 Duo T5870 @ 2.00 GHz (2 Kerne) - 6GB RAM - Win7/64 - mit VBox Setup Win7/32 (64bit bietet VBox nicht an) RAM 1GB (4GB gesamt wg. Win32-Auswahl) - MTU 1464 + 28 = 1492 - Fritzbox VDSL 50
Edit:
zu MTU: Voreinstellung bei Windows ist wg. LAN 1500, aber alles ist lt,. Tests fragmentiert. Gefundene Literatur, z.B. Heise, (und eigene Tests heute) sagen bei VDSL50 ist mein Wert richtig. Wird auch bei Ping zu z.B. 8.8.8.8 bestätigt.
Allerdings, wenn ich vom Notebook per WLAN (FFRL) teste, erhalte ich als optimalen MTU-Wert 1400
1372 + 28 (und darauf ist mein WiFI-Adapter auch eingestellt, Wndows default ist 1500)
Edit2:
übrigens zum Vergleich: wenn ich mit WLAN direkt an die Fritzbox gehe (Heimnetzwerk), erhalte ich auch nur 30Mbit/s, allerdings ohne Schwankungen
Fazit: 50 - 100% Gewinn wenn „Versorgung“ durch Gateway(s)
Für ein 841 „in zweiter Reihe“ nicht übel
