ich betreibe einen freifunk Router in der Domäne Fichtenfunk und habe eine sehr stark Schwankende Performance.
Akut kann ich leider noch nicht einmal Whatsapp richtig nutzen. Der Empfang am Handy ist gut und der Router ist auch gut angebunden. Es ist meinem empfinden nicht unbedingt die Bandbreite das Problem sondern irgendwie gehen auch viele Pakete verloren.
Meine Frage:
Hat jemand einen ähnlichen Effekt?
Liegt das an der Anzahl der Nutzer in der Domäne allgemein oder ist hier vielleicht doch Konfigurations Problem?
IPv6 ist immer wieder eine echte Herausforderung für den FFRL-Backbone.
Ich würde vorschlagen, dem eigenen Endgeräte dessen Nutzung schlicht zu untersagen.
Mir sieht zumindest der Traceroute weniger nach einem Performance-Problem (wenn ich „Performance“ als „Durchsatz“ lese), es hakt schon eine Stufe vorher.
Da ist schlicht Packetloss.
Dass dieser Packetloss dann dazu führt, dass das nicht sinnvoll nutzbar ist und somit auch keine Performance drauf kommt, das ist dann nur Folgefehler.
Also: Ursache für die Schlechte Performance ist Packetloss!
Ja okay stimme ich voll zu aber woher könnte den der Packetloss den kommen?
Ich sitzt mit meinem PC und Handy direkt vor dem Router freifunk Router (1043ND) und der ist per Mesh-VPN über eine Unitymedia Internet Leitung angebunden. Deswegen war meine Frage ob es vielleicht an etwas liegt was ich nicht beeinflussen kann (Backbone etc.). Mein normales WLAN funktioniert nämliche ohne Probleme.
Hast du mal auf die Statusseite geguckt wie lange die fastd-Verbindung besteht? Oder hast du ssh-Zugriff auf den Knoten und kannst mal ein logread machen?
Da hilft Dir Wireshark und eine echte Analyse des Traffics.
Zu unterschiedliche MCS-Indexe können das WLAN-Mesh-Netz blockieren.
Schwankende Reflexionen oder Dämfungen können das WLAN-Mesh-Netz blockieren.
Woher können unterschiedliche MCS-Indexe kommen?
durch zu hohe Sendeleistung bei zu niedriger Empfangsempfindlichkeit
durch das „drinnen - draußen - Problem“: Signale können von außen besser in Räume eindringen, als von innen die Räume verlassen. Das hat Helmholtz irgendwie (u. a. für die Akustik) beschrieben: Koppelung von Räumen.
Vielleicht hast Du auch unbehandelte Loops in deinem Netz? Batman verhindert die selbstständig, aber überall dort, wo zusätzliche Hardware (Repeater sind böse!) ins Spiel kommen, kann Batman nicht mehr weiterhelfen.
Hast Du einen WiFi-Analyser auf deinem Tablet oder Smartphone? Der hilft schon mal weiter.
Ping ist ungeeignet für das Problem. Es arbeitet mit ICMP und daher auf Layer-3.
Dein Problem steckt aber vermutlich im „Layer-0“, also noch unterhalb der offiziellen Bitschicht…
Da helfen Stehwellenmessgeräte und sonstiges Museumsgerümpel ;-))
In der Akustik würde man sagen: die Direktivität des Strahlers ist zu gering, dadurch ist der Hallradius zu gering und die Trennschärfe ist gestört. Das kann man voll auf die Antennentechnik übertragen. Zuviele Überlagerungen sorgen für Interferenzen. Diese können dann in Ihrer Intensität als Schwebung auftreten und stören damit das Verhandlungsverfahren (Ermittlung des MCS) der WLAN-Stationen.
Helfen kann da nur eine hohe Empfangsempfindlichkeit bei moderater Sendeleistung. Fahr die Sendeleistung mal zurück. Das verkleinert zwar dein Zeitfenster und damit den Datendurchsatz, verhindert aber unerkannte Kollisionen! Wir arbeiten zwar theoretisch mit CSMA/CA, aber das funktioniert nur, wenn Sendelesitung und Empfangsempdinflichkeit zusammenpassen.
Es hat heute heftig geknallt in der Technik, wir versuchen das im Laufe des Abends zu lösen und werden berichten. Die schlechte Performance von Internetdiensten ist aktuell auf ca 30% Paketverlust auf den Fastd Strecken zurück zu führen. Das WLAN Netz und die Router laufen weiterhin stabil.
bei uns in Gummersbach ist der Packetloss allerdings in den letzten Wochen immer wieder eklatant aufgetreten.
Ich wollte mich erst melden, wenn ich ein paar weiterer Tests bei anderen Routern durchgeführt habe, aber ich kann ja schonmal einen smokeping der letzten 10 Tage anfügen. Hier wird ein HTTP Request von einer Raspi-FF-Bake auf einen Server in einem Rechenzentrum durchgeführt via ipv4.
Bei icmp echo ping sieht das Ergebnis ähnlich aus. Der durchschnittliche Paketverlust liegt bei 5-6%. In den Mittagsstunden deutlich mehr. Getestet wurde auch mit unterschiedlichen Routermodellen.
Dann schau doch mal, ob du von Deinem Heimnetzwerk aus mit einem mtr (oder ähnlichen tool), den Paketverlust „von Dir zum fastd-Server“ ermittelst. Also „Außerhalb des Tunnels“, nicht „innerhalb des Tunnels“ (worauf sich Dein Graph vermutlich bezieht)
Da scheint es häufig Engpässe zu geben. (Wenn diese Strecke schon Loss hat, dann kann der beste Fastd nichts mehr helfe, weil das (fast) alles UDP ist.)
Problem gelöst, der Paketverlust ist bei den meisten Tunneln jetzt wieder auf 0% hier und da sind 2-5%
Wenn es irgendwo Probleme gibt bitte folgende Infos Liefern (Für die Tests per Kabel ans Freifunk hängen):
besten Dank für Deinen Einsatz! Die Situation in Gummersbach scheint sich deutlich verbessert zu haben, es gibt aber immer noch recht viele Paketverluste in Stoßzeiten, welche bei paketvermittelten Diensten zu spüren ist. Ich muss aber erstmal schauen ob sie im Funk oder auf der Leitung stattfinden. Bei http/s klappt es deutlich besser als vorher. Ich werde die Situation in den nächsten Tagen weiter im Auge behalten und mich bei Bedarf mit Deiner Diagnoseanforderung zurückmelden. Vielen Dank nochmals!
Ein schönes Wochenende und viele Grüße aus Gummersbach,
Ulf
ich habe seit Tagen wieder einen sehr hohen Packtloss und dadurch eine miserable Usability im Freifunk Netz. Ich denke es liegt nicht an mir. Kannst du mal nachschauen ob es ein generelles Problem gibt?
Hier deine geforderten Daten:
Ping-Statistik für 10.224.16.1:
Pakete: Gesendet = 100, Empfangen = 75, Verloren = 25 (25% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 79ms, Maximum = 1435ms, Mittelwert = 142ms
Ping-Statistik für 10.224.8.1:
Pakete: Gesendet = 100, Empfangen = 85, Verloren = 15
(15% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 19ms, Maximum = 98ms, Mittelwert = 38ms
1 40 ms 48 ms 48 ms 10.224.8.1
2 31 ms 36 ms 27 ms 10.0.8.1
3 72 ms 71 ms 75 ms 100.64.3.150
4 * 77 ms 96 ms strato.nikhef.nl-ix.net [193.239.116.37]
5 * * * Zeitüberschreitung der Anforderung.
6 69 ms * 89 ms rbx-g2-a9.fr.eu [94.23.122.78]
7 * 154 ms 123 ms vss-11a-6k.routers.ovh.net [37.187.231.245]
8 82 ms 81 ms 72 ms 51.254.175.255
ja, ich messe parallel zur Messung „innerhalb des Tunnels“ auch aus meinem privaten Wlan am Kabelrouter, an dem auch der FF-Router hängt, zur Referenz mit einer zweiten Bake „außerhalb des Tunnels“, welche ohne Probleme läuft. Ich wollte das Forum jetzt nicht mit Graphen zuschmeissen.
Ich werde zusätzlich mal den fastd-Server anpingen und dann sehen wir weiter.
Wie es scheint gibt es ja laut jjx doch irgendein generelles Problem. Sobald das behoben ist und bei mir der Fehler immer noch auftritt gehe ich weiter auf Fehlersuche.
Wenn ihr Bescheid wisst und daran arbeitet dann ist ja gut. Danke dafür. Manchmal bekommt man sowas ja auch gar nicht mit. Gerade so ein Packtloss merkt man ja nur wenn man ein Monitoring hat oder selbst im Freifunk Netz online ist.
Falls ich noch was tun oder helfen kann sag bescheid.
