Heppenheim - Eine Analyse

In den letzten Wochen kam immer wieder das Thema auf, ob unser Netz denn nicht zu groß ist und es deshalb Probleme in Heppenheim gibt. Die beschriebenen Probleme waren eine schlechte Link Qualität (TQ) und ein geringer Durchsatz.

Von Beginn an hatten @Cheatha, @lukasbisdorf und ich damit argumentiert, dass es zu wenige Uplinks gibt und auch die schlechten Links zwischen den Knoten weitere, schwer zu analysierende Probleme verursachen.

Das mit den Uplinks wurde dann nach einiger Zeit auch angegangen. Das war ein erster wichtiger Schritt.

Leider ist dann dieses Thema und ein paar weitere Themen eskaliert, so das wir viel Zeit in schwierige, zum Teil leider unsachliche, Diskussionen statt Debugging stecken mussten. Letztlich wurde das, eigentlich lokale, Thema in das Deuschland-Forum gebracht, vermutlich, da es eine Unzufriedenheit mit unseren Antworten gab. Leider ist uns bis heute nicht klar woran das genau lag. Dort im Forum wurde dann die Theorie aufgestellt, dass Netze mit mehr als 100-200 Knoten zu groß sind und das Grundrauschen das Problem ist. So ist dann auch der Vorschlag eines Domänensplits entstanden und ins Spiel gebracht worden. Unsere, auf Daten und Zahlen basierende, Gegenargumentation fand im Forum leider kein Gehör.

Zu den Themen Meshing und Geschwindigkeit habe ich auch zwei weiterführende FAQ Artikel geschrieben, die ihr hier findet: Wie viele Mesh Knoten kann ich ohne Uplink hintereinander schalten? und Wird das Netz durch mehr Knoten langsam?

Leider wurden unsere Argumente, wie bereits erwähnt, nicht wirklich angenommen und es wurden stattdessen andere Argumente angebracht, die nicht fundiert belegt wurden. Trotz allem haben wir permanent weiter die Probleme untersucht und sind froh, jetzt endlich eine ausführliche Analyse und Handlungsempfehlung vorstellen zu können.

Diese untermauert unseren Standpunkt und unsere bisherige Argumentation und spricht eindeutig gegen die Größe des Netzes als Ursache.


Mitte letzter Woche hat mich Lukas in einem Gespräch über die Probleme in HP noch einmal darauf angesprochen, den Fehler doch im lokalen Netz in Heppenheim zu suchen. Daraus entstanden ist dann dieses Ergebnis.

Zuerst habe ich ein Tool geschrieben, dass es ermöglicht die TQ Werte in einem bestimmten Gebiet zu überwachen. Das hat sich dann zu einer immer weitergehenen Untersuchung entwickelt, die viele der Thesen aus dem Deutschland-Forum anhand von realen Daten widerlegen kann.

Aber erstmal auf Anfang. Dabei habe ich begonnen die Links in einem Gebiet in und um die Fußgängerzone in HP zu beobachten und dafür Graphen im Grafana zu erzeugen. Dabei hat sich gezeigt, das die TQ hier währen dem Tag (Werktags) bei etwa 40% liegt. Das ist wirklich sehr wenig. Gleichzeitig hat sich gezeigt, dass dieser Wert Nachts auf bis zu 70% ansteigt. Hier könnte man noch die Theorie aufstellen, dass es mit einem Nachts geringeren Grundrauschen zu tun hat. Dies ist jedoch nicht so, das können wir widerlegen.

Zusätzlich zu den TQ-Werten habe ich auch den oben zu sehenden Graph mit der Anzahl der Links im Vergleich zur TQ erzeugt. Dieser zeigt insbesondere morgens zwischen 8 und 9 Uhr einen starken Anstieg der Links und einen Abfall der TQ. Das ist der Moment, in dem die Knoten angeschaltet werden, die Nachts abgeschaltet waren.

Es zeigt sich, dass die TQ besser ist, wenn Nachts einige der Knoten abgeschaltet sind und sie ebenfalls sinkt wenn die Zahl der Mesh Verbindungen steigt. Das bestätigt die Theorie, dass sich die Knoten gegenseitig stören. Die Ursache ist das Hidden Station Problem: Dieses Problem führt dazu, dass z.B. Knoten A und C (die sich über Funk nicht sehen) gleichzeitig zu senden beginnen und B (der beide empfängt) dann diese Daten verwirft und beiden meldet, dass sie gleichzeitig gesendet haben. Es geht also für einen ganzen Moment gar nichts mehr. Das Problem ist schon bei drei Knoten problematisch, daran erkennt man, wie schwer es erst in einem Setup wie in der Fußgängerzone wird.

Es liegt aber nicht ausschließlich an dem Hidden Station Problem. Leider sind die Verbindungen an sich auch nicht sehr gut. Dies liegt vermutlich an einer nicht optimalen Positionierung der Knoten. Diese sollten so nah an der Fensterfront wie möglich positioniert werden.

Das zeigt sich, wenn wir die Daten aus HP mit dem übrigen Netz vergleichen.

Im obigen Graphen erkennt man, dass die TQ in der Fußgängerzone um etwa 42% geringer ist, als im übrigen Netz wenn man Heppenheim raus rechnet. Gleichzeitig gibt es die oben bereits beschriebenen Probleme auch in den Unterkünften in HP. Denn die TQ von ganz Heppenheim im Vergleich zum übrigen Netz liegt noch immer 27% niedriger.
Diese Werte sind ohne die VPN Verbindungen zu unseren Gateways, rechnet man diese mit rein, sind die Verbindungen in HP sogar noch mal 1-2% schlechter als im Schnitt.

Daher ist die klare Handlungsempfehlung um die Probleme zu lösen: die Positionen der Knoten muss verbessert werden. Überflüssige Knoten müssen abgeschaltet werden, sie stören mehr als dass sie helfen. Hier muss man dann auch etwas experimentieren, bis die richtigen Positionen gefunden sind.


Damit ist die Analyse jedoch nicht abgeschlossen, es gilt schließlich noch zu belegen, dass die Größe des Netzes keinen direkten Effekt auf die TQ hat.

Dazu habe ich weitere Daten, auch von anderen Communities, analysiert. Beispielhaft sind hier FFRN, Freifunk Hamburg (etwa 300 Knoten größer als wir), Darmstadt (etwa 300 Knoten kleiner als wir) und Düsseldorf (etwa 200 Knoten). Bei diesen Messungen wurden alle Link Werte erfasst, also sowohl VPN TQ als auch WLAN Mesh TQ.

Hier zeigt sich schon recht deutlich, dass eine Schwankung um bis zu 300 Knoten in beide Richtungen keinen Effekt auf die TQ erzeugt. Einzig Düsseldorf hat eine merkbar höhere TQ. Aber auch das lässt sich erklären und hängt nicht mit der Zahl der Knoten zusammen.

Obige Grafik zeigt dabei, dass die Zahl der Links steigt, wenn die Zahl der Knoten steigt. Das ist ein Verhalten das zu erwarten ist.

Die letzte Grafik zeigt, dass es jedoch einen Zusammenhang zwischen TQ und dem Verhältnis zwischen Zahl der Knoten und Zahl der Links gezogen werden kann. Dies zeigt sich auch dadurch, dass Communities mit einer ähnlichen TQ eine ähnliche Mesh Ratio haben, wie z.B. FFRN und Darmstadt. Gleichzeigt erklärt dieses Verhältnis auch, warum größere und kleinere Communities eine bessere TQ haben können, denn diese haben eine viel geringere Zahl von Mesh Verbindungen pro Knoten und damit auch eine statistisch signifikant niedrigere Wahrscheinlichkeit für komplexe und damit fehleranfälligere Mesh Konstrukte.

Somit zeigt sich, dass es aktuell keinen direkten Zusammenhang zwischen TQ und irgendwelchen, nicht lokalen, Netzvariablen gibt.

10 „Gefällt mir“

Spannende Daten, will ich erstmal verdauen. Eine Idee möchte ich aber noch loswerden:

Kann man ein Skript schreiben, dass für eine begrenzte Zeit das Netz mit Batman-Broadcast-Paketen überfällt? Sagen wir 100 und 200 zusätzlich simulierte Knoten. Wenn man das Skript dann mal eine Stunde laufen lässt, sollte man doch sehen, was mit dem Netz passiert. Dann würde man auch nicht unterschiedliche Netze vergleichen (wobei ich das oben geschreibene nicht abwerten will), sondern einen echten Vergleich erzeugen, bei dem die andere Randbedingungen gleich bleiben.

Wenn man es nachts laufen lässt zwischen 2:00 und 3:00 sollte der Einfluss auf Nutzer gering sein. Wenn man das ein paar Nächte macht, sich langsam an höhere simulierte Kontenzahlen rantastet und dann auch mal tagsüber fährt (mit simulierten Knotenzahlen, die nachts noch keinen Schaden machen) dann hätte man schnell eine ziemlich robuste Statistik. Man könnte dann auch halbwegs klar sagen wo die Grenzen liegen oder nicht liegen.

Ich gebe zu, dass die Diskussion im Deutschland-Forum sehr in die Richtung kleiner Netze geht, aber es ist auch so, dass da vor allem ein Ökosystem von Freifunk Rheinland mit teilweise zusammenhängender Backbonestruktur so argumentiert. Andere große Netze tauchen da nicht in großer Zahl in der Diskussion auf. Ich habe es jedenfalls in den letzten Wochen nicht geschafft, mir genug Wissen anzulesen, um eine klare Meinung zu haben. Ich sehe potentielle Probleme, kann die aber in ihrer Gewichtung nicht final einschätzen. Daher mein Vorschlag zu Experimenten.

Danke für Deine Arbeit @leah im Alltag des Betriebes und im speziellen bei der Problemlösung.

Das dürfte sehr sehr Aufwändig werden, da wir dafür einen ganzen Knoten mit allen Interaktionen und realistischen WLAN Links simulieren müssten. Dazu kommt, das wir dann auch noch die entsprechenden Clients und extra Gateways simulieren müssten und am Ende ist es doch nur eine Simulation. Das geht leider nicht wirklich gut, da du so quasi jedes Ergebnis erzeugen kannst.
Ich habe bei den Netzen explizit darauf geachtet, vergleichbare Netze zu nehmen + Düsseldorf und somit sind die Werte durchaus vergleichbar und näher an der Realität als es jede künstliche Simulation sein könnte.

[EDIT] Ach ja, ich hab das Ganze auch beobachtet, wenn mal eine große Unterkunft mit ca. 150 Usern offline gegangen ist, hat auch keinen Unterschied gemacht :)[/EDIT]

Ich denke nicht, dass die Geräte heute schlechter positioniert sind als vor einem halben Jahr.

Fußgängerzone am 07.10.2015:

Und heute, 30.03.2016:

Popelig formuliert:

Es kann also sein, dass ein paar zusätzliche Knoten in ungünstiger Position das gesamte Mesh deutlich verschlechtern…
Besonders dann, wenn dadurch eine klare, aber schwache und direkte Beziehung zwischen zwei Knoten durch einen neuen Knoten so gestört wird, dass ein/mehrere Hidden-Station-Problem(e) entsteht.

Also zu wenig Knoten, oder zu viele … um richtig zu funktionieren?

Ok, anscheinend habe ich das nicht ausreichend erklärt:

Das mag bei den Geräten aus dem ersten Screenshot durchaus stimmen. Leider hat sich aber die Gesamtsituation seit dem sehr stark geändert. Es sind nämlich überall neue Knoten dazu gekommen. Sind diese nicht sorgfältig platziert, kommt es zu dem bereits beschriebenen Hidden Station Problem und Verwandten davon. Es muss beim Erweitern eines Meshs also auch darauf geachtet werden, dass neue Knoten nicht die Übertragungen der alten Knoten stören. In dem von dir Beispielhaft markierten Link kann dies durch einige neue Knoten passieren, wie den Knoten in der Willhelmstraße, den in den Cafés oder im Sehzentrum um nur eine Auswahl zu nennen.

An manchen Knoten lässt sich das durch die erwähnte bessere Positionierung ändern. Bei anderen Knoten ist die Abschaltung vermutlich die bessere Idee. Wie gesagt, hier muss experimentiert werden, welches die beste Lösung ist.
WLAN Netze sind leider keine triviale Angelegenheit.

Eine schöne Erklärung der Problematik findet man auch hier: Probleme

An den falschen Stellen kann das auf jeden Fall passieren.

In Heppenheim werden es, wie schon angedeutet, zu viele Knoten auf zu wenig Raum mit zu schlechter Ausrichtung aufeinander sein.

Hallo, ich halte nichts von einer komplexen Simulation. Zu aufwändig, muss man können und durch die vielen Annahmen, die man machen muss hat man so viele Freiheitsgrade, das man sich alles zurechtsimulieren kann. (Ich habe mal professionell andere Dinge simuliert und mich immer drüber geärgert, was Leute in schöne Bildchen oder Spezialfälle hereininterpretieren.)

Meine Annahmen waren:

  • Der Management Overhead besteht hauptsächlich aus den BATMAN-Broadcast-Paketen.
  • Wir würden die Zahl der Gateways mitskalieren. Die Zahl der Knoten, die an einem Gateway hängen bleibt grob gleich.

Dann würde ein Knoten in HP von einem zusätzlichen Knoten in Ma nichts mitbekommen außer des zusätzlichen Batman-Broadcast-Verkehrs. (Wenn beide an unterschiedlichen Gateways hängen) Nutzlast Richtung Gateway und Internet würde aus MA ja nicht nach HP gehen.

Warum ich das spannend finde ist, dass für die BATMAN-Broadcast-Pakete im WLAN die Senderate gedrosselt wird, damit auch ältere Geräte im Netz mitmachen können. (Adorfer bei forum.freifunk.net , ich hatte noch eine zweite Quelle, suche aber noch. Update, wenn ich sie gefunden habe.) Dadurch verbrauchen die kleinen Pakete überproportional viel Airtime. Das ist das einzige, wie ich mir vorstellen kann, dass die Netzgröße die Performance beeinflusst, weil das durchgesetzte Datenvolumen so ja eher nicht nach Problem aussieht. Das sähe ich gerne ausgeschlossen.

Ansonsten bin ich auch viel mehr bei: „Wir haben die systemischen Grenzen noch nicht erreicht.“ Und würde eher Richtung Zahl der Uplinks und Erreichbarkeit der Knoten weitersuchen wollen.

Private Anekdote: Mein Knoten zu Hause ist auf den Balkon gewandert, weil ich damit die Wohnung gut genug ausgeleuchtet bekomme und draußen mehr andere Clients erreicht werden. Vielleicht ist das ein Ansatz, die vielen Knoten von hinter der Scheibe vor die Scheibe zu holen und damit das Mesh zu stärken.

Das könnte man unterbinden, wenn man auf „B“ verzichtet. Es gibt in meinem Zoo an Geräten kein einziges mehr, welches nicht wenigstens „G“ könnte. Also anstelle von B,G,N nur noch G,N bei 2,4GHz.

Ich weiß nicht ob @leah das irgendwo aus den Statistiken graben kann, aber meines Erachtens ist das inzwischen bei Laptops und Smartphones völlig überflüssig! Ich würde vermuten, dass es nur noch extrem wenige Geräte betrifft, aber alle leiden darunter.

Das ist dann glaub ich bei dir falsch angekommen. Die BATMAN Pakete reduzieren nicht die Senderate. Die operieren auch auf einem ganz anderen Netzwerk Layer als der auf dem die Senderate festgelegt wird. Die MCS ist nur eine Tabelle mit Werten, über die der theoretische Durchsatz eines WLAN Links anhand der Codierung bestimmt werden kann. Mit der echten darüber erreichbaren Datenrate hat aber auch das nichts zu tun.

Der von Adorfer genannte 12Mbit/s Wert ist die so genannte Multicast Rate. Die Beschreibt mit welcher Geschwindigkeit Broadcast und Multicast Pakete übertragen werden und damit auch, ab welchem MCS Wert ein Link als solcher akzeptiert wird. Der Grund dafür ist, dass so sichergestellt wird, dass jeder Client egal mit welcher Datenrate auch die Broadcast/Multicast Nachrichten erhält. Das macht so also schon Sinn und ist in jedem WLAN so. Regulär ist der Wert allerdings deutlich niedriger. Das hat mal Vorteile, mal Nachteile. Ist nen ziemlich komplexes Thema.
Im Falle der von uns verwendeten Multicast Rate von 12Mbit/s werden erst WLAN Links (sowohl Client als auch Mesh) angenommen, die mindestens 12 Mbit/s Durchsatz erreichen können. Dieser Wert ist auch nicht willkürlich festgelegt und damit kommen wir zur Anmerkung von @bitboy0. Denn die Mulicast Rate von 12Mbit/s hält uns potenzielle 802.11b Clients oder APs vom Hals, da diese nur eine maximale Rate von 11Mbit/s unterstützen :)

2 „Gefällt mir“

Danke, das hilft weiter.

Nur falls ich zuviel Frage oder in Frage stelle: Ich habe schon das Gefühl, das FFRN grundsolide aufgebaut ist und nicht alle Probleme aus anderen Netzen gleich auf uns übertragen werden können.

1 „Gefällt mir“

Wie immer gesagt wird: Fragen stellen ist ausdrücklich erwünscht :) Wir versuchen dann auch immer zu Antworten und eine verständliche Erklärung zu liefern :)

6 „Gefällt mir“

Hallo zusammen,

ich bin Matthias aus dem Freifunk Münsterland und habe den Heppenheimern die letzten Tage geholfen, eine eigene Domäne für Heppenheim aufzusetzen. Das ist soweit fertig. Das zwischenmenschliche in eurer Community geht mich auch gar nichts an, aber ich kann das Gefühl sehr gut nachvollziehen, wenn man Freunden und Bekannten von Freifunk vorgeschwärmt hat, diese Geld investiert haben, und es dann nicht läuft. Das kann persönlich sehr unangenehm und belastend sein und habe ich aus erster Hand erlebt. Daher habe ich ein wenig Starthilfe geleistet.

Nun zum technischen. Eure Analysen sind interessant und vermutlich ist hier auch der bessere Ort dazu die Probleme zu analyiseren als im großen Forum, wo es manchmal etwas ruppig wird und man schnell in Schubladen gesteckt wird.

Erstmal muss ich sagen, dass ich für die Größe des Netzes von dessen Performance noch eher beeindruckt bin. Unser Netz lief mit 1000 aktiven Knoten deutlich schlechter, da wir massive DHCP-Probleme hatten. Davon lese ich hier bisher gar nichts. Das ist schon mal gut. (Da würde mich mal euer DHCP-Konzept interessieren, aber das ist ein anderes Thema.)

Was ich hier aber noch gar nicht lese, ist folgender, exponentieller Zusammenhang: Jeder Knoten muss jeden kennen. Dazu versendet batman sogenannte Originator (Hallo-hier-bin-ich-)Pakete und die müssen auf jedem Knoten verarbeitet werden. Jedes ankommende Paket kostet Rechenzeit. Wenn man dann noch fastd nutzt, das im Userspace läuft, kann es schnell dünn werden auf den kleinen Prozessoren. Das kann man sich übrigens mit

batctl o

auf den Knoten anzeigen lassen. Und das ist auch der Grund, warum fastd-Offloader wie der Futro oder Desktop-CPUs mit Gluon immer noch gut in großen Domänen funktionieren.

Analyisert das ganze doch mal Stück für Stück, z. B. folgender Testaufbau:

  • 841er, WLAN komplett deaktiviert, also sowohl Client als auch Meschnetz
  • LAN-Mesh aus damit man sich über Kabel verbinden kann
  • Laptop per Kabel verbinden
  • Speedtest durchführen

Das ist dann ein Referenzwert, der ohne WLAN-Störungen reproduzierbar über den Tag gemessen werden kann. Der lag bei uns irgendwann unter 4 Mbit/s und war nicht mehr tollerierbar.

Problematik mit Meschknoten. Da gibt es zwei Probleme.

  • Erstens muss das gesamte Grundrauschen über jeden einzelnen Meschlink. Da wird also kontinuierlich Müll gesendet
  • Zweitens brechen Meschlinks in Fußgängerzonen und Flüchtlingsheimen, allgemein überall, wo viele verbundene Geräte sind, immer ein. Wenn 15 Geräte an einem Knoten hängen, ist der so damit beschäftigt die ganzen Broadcasts an die Clients auszuliefern, dass kaum noch Zeit bleibt, den Uplink bzw. das Meschnetz zu bedienen. Das Problem tritt unabhängig von der Knotenanzahl immer auf. Hier kann man mit einem zweiten Router an jedem Standort das Mesch- und Clientnetz auf verschiedene Kanäle legen. Also z.B. zwei 841er über Kabel verbunden, einer auf Kanal, der sich um das Mesch kümmert, und einer z. B. auf Kanal 5, der das Clientnetz abwickelt.

Wenn es früher besser lief, kann es schlicht daran liegen, dass noch nicht so viele Handys eure SSID gespeichert hatten. Hier am Besten mal die Clientzahlen aus besseren Zeiten zum Vergleich daneben legen.

Layer-2-Netze skalieren nicht. Das ist irgendwie seit Jahrzehnten bekannt und daher hat man das mit dem IP-Zeugs erfunden. Also kann ich euch nur empfehlen, euch da nicht zu sehr drauf zu versteifen, das jetzige Netz in seiner Größe flotter zu machen. Das wird früher oder später an der Leistung der Routerprozessoren scheitern.

Dies mal so als frische Perspektive von außen.

Liebe Grüße
Matthias

Ergänzung: Gerade noch die Karte aus dem oberen Beitrag entdeckt (Heppenheim - Eine Analyse). Da sieht man, dass da kaum Clients dran sind. Also ist das Problem die Knotenanzahl im gesamten Netz.

1 „Gefällt mir“

Hallo @MPW erstmal sehr schade das da jetzt scheinbar so viel ohne auch nur ein Gespräch mit der existierenden Community gelaufen ist. Auch an dich ein kleiner Rüffel das da nicht auf ein Gespräch hingewirkt wurde. Das ist wirklich sehr schade. Die Analyse:

halte ich für vorschnell. Das Problem in HP habe ich ja oben schon ausführlich dargelegt, das muss ich nicht nochmal machen. Das Problem liegt an einer ganz anderen Stelle. Ich kann z.B. auch deinen Wert von 4Mbit/s nicht nachvollziehen, ich bekomme an meinem und vielen anderen 841ern mit entsprechend schnellem Anschluss 10-16Mbit/s. Der Rest ist uns auch bekannt und wir wissen das wir ab einer bestimmten Größe splitten müssen. Aber in HP liegen die Problem anders. Leider wurde darauf aber nie eingegangen und stattdessen jetzt scheinbar eine neue Community gegründet.

2 „Gefällt mir“

Yeah, ich wurde gerüffelt. Ist das hier das hier ein Award?

Ne im Ernst, wie gesagt. Ich hab mit dem zwischenmenschlichen bei euch echt mal so gar nichts zu tun und habe nur an der technischen Diskussion ein Interesse.

Ich habe den Artikel auf eurer Internetseite jetzt nicht gelesen, da er mir nicht vorliegt, aber guck dir einfach mal diesen Beitrag an: Heppenheim - Eine Analyse

Die Karte zeigt denselben Ausschnitt, mit grob derselben Anzahl an Knoten und fast ohne Clients. Was hat sich außer dem Zeitstempel geändert? Die Anzahl der Knoten im Gesamtnetz!

Da jetzt zu behaupten, dass es keinen Zusammenhang gilt, halte ich für unlogisch und ignorant.

Ich schlage mal ein Mumble vor, dann können wir das ausführlicher diskutieren, ohne uns die Finger wund zu tippen.

Bei uns in Münster hat sich auch eine Subcommunity ausgruppiert, um technische Experimente durchzuführen und inzwischen sind wir wieder alle vereint. Also betrachte es als Chance, statt hier irgendwie Rüffel zu verteilen.

1 „Gefällt mir“

Vielleicht haben die beiden auch einfach nicht verstanden, was die Ziele von Freifunkt sind? Eigentlich wollen sie doch nur den Hotspot und der ist nur ein Feature von Freifunk und kein Muss. Die Enttaeuschung ist also irgendwie auch selbstgemacht, da ohne vorherige Reflektion der Vereinsziele geworben und investiert wurde.

Jetzt sind sie im Zugzwang und machen ihr eigenes Ding und muessen auch rechtlich dafuer gerade stehen. Ich persoenlich wuerde ohne Vereinsstatus kein Gateway fuer „freien Funk“ ins Internet auf meinen Namen anmelden.

Danke fuer Deine technischen Ausfuehrungen.

Nein, das ist ein Aussage, das ich es schön gefunden hätte, wenn irgendwer Rücksprache mit der existierenden Community gehalten hätte.

Du findes ihn hier im Thread ganz oben. Er liegt dir also vor. Das du ihn nicht gelesen hast, hab ich mir schon fast gedacht. Um es mit deinen Worten zu sagen, vielleicht ist das: „unlogisch und ignorant“

Die Karte zeigt den selben Ausschnitt mit einem großen zeitlichen Abstand. Seit dem sind viele Knoten ohne Uplink dazu gekommen. Dazu gibt es lustige Hidden Station Probleme. Lies doch bitte die Infos auch durch bevor du hier mit unlogisch und ignorant kommst.

Absprache, es geht alles um Absprache. Die ist hier nicht passiert.

4 „Gefällt mir“

Ach du meinst sowas?

$ whois 2a01:4f8:100:57ff:f6f2:6dff:fedc:3c5e
% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See http://www.ripe.net/db/support/db-terms-conditions.pdf

% Note: this output has been filtered.
%       To receive output for a database update, use the "-B" flag.

% Information related to '2a01:4f8:100:5700::/56'

% Abuse contact for '2a01:4f8:100:5700::/56' is 'abuse@hetzner.de'

inet6num:       2a01:4f8:100:5700::/56
netname:        LEAH-OSWALD-IT-SERVICE-UND-CONSULTING
descr:          Leah Oswald IT-Service & Consulting
country:        DE
admin-c:        BO1327-RIPE
tech-c:         BO1327-RIPE
status:         ASSIGNED
mnt-by:         HOS-GUN
created:        2014-06-02T05:35:07Z
last-modified:  2014-06-02T05:35:07Z
source:         RIPE # Filtered

person:         Leah Oswald
address:        Leah Oswald IT-Service & Consulting
address:        Fichtestra�e 75
address:        69469 Weinheim
address:        GERMANY
phone:          +4962013898387
nic-hdl:        BO1327-RIPE
abuse-mailbox:  abuse@root-space.de
mnt-by:         HOS-GUN
created:        2011-07-02T00:40:31Z
last-modified:  2014-05-28T15:12:29Z
source:         RIPE # Filtered

% Information related to '2a01:4f8::/29AS24940'

route6:         2a01:4f8::/29
descr:          HETZNER-RZ-NBG-IPV6-BLK1
origin:         AS24940
org:            ORG-HOA1-RIPE
mnt-by:         HOS-GUN
created:        2012-08-31T12:01:28Z
last-modified:  2012-08-31T12:01:28Z
source:         RIPE

organisation:   ORG-HOA1-RIPE
org-name:       Hetzner Online GmbH
org-type:       LIR
address:        Industriestrasse 25
address:        D-91710
address:        Gunzenhausen
address:        GERMANY
phone:          +49 9831 5050
fax-no:         +49 9831 5053
admin-c:        TF2013-RIPE
admin-c:        MF1400-RIPE
admin-c:        GM834-RIPE
admin-c:        HOAC1-RIPE
admin-c:        MH375-RIPE
admin-c:        SK2374-RIPE
admin-c:        SK8441-RIPE
mnt-ref:        HOS-GUN
mnt-ref:        RIPE-NCC-HM-MNT
mnt-by:         RIPE-NCC-HM-MNT
abuse-c:        HOAC1-RIPE
created:        2004-04-17T11:07:58Z
last-modified:  2015-08-06T12:01:31Z
source:         RIPE # Filtered

% This query was served by the RIPE Database Query Service version 1.86 (DB-2)

Bei euch steht Hetzner als Abuse drin. Zwei drei Torrent-Nutzer, die urheberrechtlich geschützte Daten teilen, und die machen euch die Kiste aus. Die Heppenheim-Domäne routet über das Backbone des Freifunk Rheinland e. V.

Bzgl. der Rücksprache, klärt das bitte mit den Heppenheimern. Ich hab damit nichts zu tun.

Du meinst aber nicht das hier oder? Wird das Netz durch mehr Knoten langsam?

Du musst das trennen. Der Durchsatz hängt nicht von der DSL-Leitung ab, sondern der CPU der Knoten. Die müssen nämlich das Grundrauschen auch verarbeiten, oder glaubst du, die routen das nach /dev/null? Alle Originator-Pakete müssen verarbeitet werden, Broadcasts weiter geleitet werden usw. Darum geht auch in großen Domänen mit x86-CPUs alles super. Weil die das mit links machen oder sogar mehrere Kerne haben. Aber die Knoten haben nur einen MIPS-Prozessor.

Genau. Ich nehme an, dass sich die WLAN-Chips nicht abgenutzt haben. Was sich geändert hat, ist die Anzahl der Knoten im gesamten Netz.

Die Anzahl der Knoten spielt deiner Logik nach keine Rolle. Es könnte also höchstens ein Hidden-Station-Problem sein. Und das sehe ich dort oben nicht, es sei denn, die sind alle nicht auf der Karte. Dazu mal den Graph betrachten.

Ich hab das selbst beobachtet. Wenn ich eine neue Domäne aufsetze, und diese nur einen Knoten und ein Gateway hat, gehen 12 Mbit/s durch einen 841er V8. Wenn erstmal 50 drin sind, schon nur noch 10 usw. Das konvergiert sehr langsam, aber stetig gegen null.

Ich glaube dir gut und gerne, dass es mit 650 noch gut lief, das war bei uns auch so. Aber 1000 sind bei einem exponentiell ansteigenden Problem eine ganz andere Hausnummer.

1 „Gefällt mir“

Was mich angeht… hier ein User neu, der schreibt teilweise interessante Dinge und in einem Tonfall, den ich persönlich gar nicht mag. Und der kümmert sich - laut eigenen Aussage - nicht um persönliche Unstimmigkeiten, aber sorgt für mächtig uncoole Stimmung hier.

Und wenn ich so den Tonfall nachklingen lasse, dann höre ich ein kleines Echo … als hätte ein anderer aus Heppenheim den gleichen Tonfall eingeschlagen und der ist rein zufällig anscheind schon länger mit dem neuen User im Gespräch.

Nein, das hat alles nichts mit nichts zu tun…

3 „Gefällt mir“

@MPW so langsam ärgere ich mich wirklich über dich.

Das ist ein von meiner Firma an FFRN vergebenes Netz. Da ist nix privat. In Zukunft ziehen wir aber eh auf ein anderes vereinseigenes Prefix um.

Noch nie passiert und ich verstehe mich mit deren Support super, selbst wenn mal was ist :)

Das ist doch schon etwas witzig, denn du hast ja hier doch aktiv etwas gemacht, also hängst du schon mit drin.

Nein ich meine den Thread in dem wir aktuell hier gerade jetzt schreiben.

Ich muss langsam leider vermuten, dass dir genau so wenig an einer Lösung des Problem liegt wie gewissen Herrschaften aus HP. Guck dir doch mal die Bilder an und lies nochmal was ich geschrieben habe.

Dann erklär mir bitte warum ich an nem 841er in unserem Netz noch 16Mbit/s bekomme. Aber hey, warum Diskutiere ich das mit dir, du hast ja nix damit zu tun.

1 „Gefällt mir“

@leah die Anzahl an KNOTEN kann ja auch nicht das Problem sein. Die ist in der Nacht kaum anders als am Tag und es läuft prima dann. Heppenheim hat diesbezüglich offensichtlich andere Probleme und das hast du ja auch gut erklärt.

3 „Gefällt mir“