Fortsetzung der Diskussion von Eigentlich ist das enttäuschend
Ich versuche hier nochmal, aufzuklären warum es nicht schneller wird.
Fragestellung:
Ich habe eine 16MBit/s Internetanbindung, warum bekomme ich über Freifunk nicht die volle Bandbreite meines Anschlusses?
Dies hängt von mehreren Faktoren ab:
- Auslastung der Freifunk Gateways deiner Community.
- Auslastung des VPN Exits der vom Gateway verwendet wird.
- Art des VPN Tunnelprotokolls (fastd oder L2TP).
- MTU deines Internetanschlusses.
- Art des verwendeten Freifunk Routers.
- Verbindung über WLAN oder LAN Kabel zum Freifunk Router.
- Peering zum Speedtest-Server
Gateways:
Freifunk Communitys nutzen s.g. Supernodes oder auch Gateways genannt. Dieses „sammeln“ den Traffic aller Freifunk Router und leiten ihn dann über einen VPN Exit zurück ins Internet.
Hierbei ergeben sich 5 Schwierigkeiten.
- Die Bandbreite des Gateways ist ausgelastet, somit bleibt nicht mehr genug Bandbreite für die volle Auslastung deines Anschlusses. Ein Gateway mit GBit/sec-Anschluß kann 10 VDSL100-, 20 VDSL50- bzw. 62 ADSL16-Zugänge bedienen. Rechnerisch beötigt eine Communitiy also je 500 Knoten 8 Gateways, jeweils mit GBit/sec-Anbindung, um minimal 16 MBit/sec per Anbindung sicherstellen zu können — bei höheren Durchsätzen entsprechend mehr Gateways mit weniger Knoten/Gateway.
- Deine Community nutzt das Tunnelprotokoll fastd, dies erfordert auch auf den Gateways viel CPU-Leistung, ggf. ist die derzeit verfügbare CPU-Zeit nicht ausreichend (noisy neighbour). Bei Nutzung von L2TP liegt das erwartete Limit bei ca. 90% der Bandbreite (siehe 1), damit bei üblichen Setups deutich über dem, was mit fastd möglich ist.
- Das Peering zwischen Deinem Anschlussprovider und dem Hoster des Gateways der Community ist der Flaschenhals. Die Effekte sind abhängig von Tageszeit und Wetterlage unterschiedlich, völlig immun ist jedoch kein Anbieter. (Einige erwecken jedoch den Anschein, „mehr Durchsatz/weniger Paketverlust/weniger RTT“ nur gegen „mehr Geld“ zu liefern zu wollen. Das Spannungsfeld zwischen „Consumer-Breitbandanschlussprovider“ und „Budget-Serverhoster“ ist dynamisch und dann mit religiösem Eifer immer wieder aufs neue diskutiert werden, da prinzipiell jeder Kompromiss ein schlechter ist.)
- Die Bandbreite oder das Peering des VPN Exits ist ausgelastet (bei FFRL-Nutzung unwahrscheinlich, aber nicht ausgeschlossen). Bei VPN-Anbietern im Ausland gilt auch eine Rechnung analog 1.zu bedenken (wieviele Kunden teilen sich den VPN-Exit-Endpunkt?).
- Peering des VPN-Exits ist zu Teilen des Internet gestört. Das ist zeitweise insbesondere bei IPv6 (facebook, google) ein Problem, glückicherweise in der Regel nur von kurzer Dauer.
Tunnelprotokoll:
Freifunk Communitys nutzen zum Schutze des Anschlussinhabers vor der WLAN Störerhaftung, ein Virtuelles Privates Netzwerk (VPN) für die Kommunikation der Freifunk Router mit den Gateways. Hier gibt es 2 verschiedene Protokolle, fastd und L2TP.
fastd
Fastd ist ein Tunnel-Protokoll, welches in vielen Communitys aufgrund der Möglichkeit zur Verschlüsselung eingesetzt wird. Im Vergleich zu beispielsweise L2TP, welches direkt im Betriebssystemkern hardwarenah als eine Art Treiber läuft, verursacht fastd wesentlich mehr CPU-Last, sowohl auf den Freifunk-Routern als auch auf den Supernodes. 15€ WLAN Router schaffen es einfach nicht, mit fastd viele Daten in Echtzeit durchzuleiten. Abhilfe schafft hier nur ein potenterer Router (WR1043v2,v3, WDR 3600/4300 (ca. 25Mbit/s), Archer C5,C7, WDR4900 (40-50Mbit/s)) als Ersatz oder als s.g. Offloader. Hier kann auch ein ThinClient Futro S550 oder jeder andere x86er PC eingesetzt werden.
Ein Offloader ist via MeshOnLan mit dem/n Router/n verbunden die beschleunigt werden sollen und übernimmt die Verschlüsselung.
L2TP
Dieses Tunnelprotokoll enkapsuliert (umschließt) den Datenstrom eines Freifunkrouters lediglich und setzt keine Verschlüsselung kein. Ferner ist es im Linux-Kern angesiedelt und beansprucht dadurch die Router-CPU weniger als Programme wie fastd oder OpenVPN. Dies zusammen bewirkt zum eine geringere Antwortzeit (Ping) sowie einen höheren Datendurchsatz. L2TP schützt auch ohne Verschlüsselung vor der WLAN Störerhaftung.
MTU deines Internetanbieters
In Deutschland kommen z. Zt., vor allem bei Kabelanbietern, verschiedene Techniken zum Einsatz, die das alte IP Protokoll IPv4 über das neue IPv6 leiten. Dies ist notwendig, da noch nicht alle Server im Internet IPv6 unterstützen.
Dies bewirkt, dass man jedem IP Paket, welches verschickt wird, zusätzliche Informationen „anheften“ muss. Dies wiederum hat zur Folge, das der nutzbare Anteil für Daten in einem Paket schrumpft. Damit die Daten nun nicht zerstückelt werden (fragmentiert), reduzieren viele Communitys die Größe der Nutzerdatenpakete auf das operative Minimum (1280 Bytes). Dies führt jedoch dazu, dass die maximal mögliche Geschwindigkeit reduziert wird, die Bandbreite sinkt.
WLAN oder LAN
Bei Speedtests ist es wichtig, die WLAN Strecke als Fehlerquelle auszuschließen. Daher sind sie in punkto maximaler Datendurchsatz nur dann aussagekräftig, wenn alle Tests per LAN Kabel durchgeführt wurden.
Peering zum Speedtest Server
Nicht immer die die Verbindung zum Netzwerk des Speedtests Servers optimal. Gerade die Telekom betreibt keine peeringfreudige Politik (peer for money). Daher sollte man den Telekom Speedtest vermeiden. Dieser wird i. d. R. immer schlechter ausfallen als Alternativen auf nperf.com oder speedtest.net.
Ich habe mir jetzt einen fastd Offloader gekauft, angeschlossen und bekomme immer noch nur 10Mbit/s?!
Die oben beschriebene MTU Problematik führt bei einfachen Verbindungen, wie bei einem Speedtest, welcher ja im Grunde nur ein einfacher Download/Upload ist, zu geringen Datenraten. Möchte man testen wieviel wirklich möglich ist, muss man die Anzahl der gleichzeitigen Verbindungen erhöhen. Ich persönlich setze dafür immer einen Torrentdownload ein. Dieser erreicht dann auch das theoretische Maximum des Offloaders.
Ich hoffe ich konnte hier nun etwas Aufklärung betreiben.
@system, @rahuelsm, @MPW, @Markus, @stefan, @Florian, @jbacksch, @SenorKaffee
Bitte zum Wiki machen.
