[Berlin-wireless] Diskussion: Auto-Portforwarding

Do Okt 26 13:14:34 CEST 2006

Gibt es eigentlich irgendwo schon konkrete Aktionen um Backbone/long haul Links auf 801.11a umzustellen ?

  _____  

Von: berlin-bounces at olsrexperiment.de [mailto:berlin-bounces at olsrexperiment.de] Im Auftrag von Dennis Bartsch
Bereitgestellt: Mittwoch, 25. Oktober 2006 21:48
Bereitgestellt in: Public Dump
Unterhaltung: [Berlin-wireless] Diskussion: Auto-Portforwarding
Betreff: Re: [Berlin-wireless] Diskussion: Auto-Portforwarding

ja, kann man. aber da gibt es zwei große probleme eher sozialer natur. zum einen ist das WSE-netz im vergleich zu damals um viele knoten gewachsen, deren besitzer scheinbar immer weniger interesse am mehr oder weniger intensiven sozielen kontakt zum rest des netzes haben, was die kentaktaufnahme nicht grad erleichtert. zum anderen kann ich dem einfachen user nich zumuten, ein startscript zu frickeln und das cron-script anzupassen, um diese änderung durchzusetzen. bevor es keinen webinterface-eintrag dafür gibt, kann man das auch nciht flächendeckend testen.

gruß
dennis bartsch
freifunk-bno.de

  _____  

> Date: Wed, 25 Oct 2006 12:26:25 +0200
> From: pbd at suspiria.net
> To: berlin at olsrexperiment.de
> Subject: Re: [Berlin-wireless] Diskussion: Auto-Portforwarding
> 
> Kann man bei den WRTs die Boradcast Datenrate nich schon per "wl mrate X" steuern ?
> Oder nutzt er dieses Setting nicht für die RTS Frames ? 
> Ansonsten wäre es vielleicht besser auf RTS zu verzichten und nur mit Fragmentation zu arbeiten.
> 
> > -----Ursprüngliche Nachricht-----
> > Von: berlin-bounces at olsrexperiment.de 
> > [mailto:berlin-bounces at olsrexperiment.de] Im Auftrag von axel
> > Bereitgestellt: Mittwoch, 25. Oktober 2006 11:57
> > Bereitgestellt in: Public Dump
> > Unterhaltung: [Berlin-wireless] Diskussion: Auto-Portforwarding
> > Betreff: Re: [Berlin-wireless] Diskussion: Auto-Portforwarding
> > 
> > 
> > On Tuesday, 24. October 2006 20:31, Dennis Bartsch wrote:
> > > mal zum "warum es nur ~500kB/s": nunja ... wenn ich zB mit 
> > iptraf nur 
> > > den olsr-traffic messe, dann kann ich rein ~25kB/s und raus 
> > ~25kB/s messen.
> > > macht zusammen ~50kB/s. im 1MBit übertragungsmodus 
> > (broadcasts eben) 
> > > macht das also rund die HÄLFTE DER SENDEZEIT. auch wieder 
> > gut messbar. 
> > > ich habe mit nem anderen freifunker zum verständnis des netzes nen 
> > > bissl
> > > rumgemessen: mitten in der nacht, wenn so gut wie kein nutz-traffic 
> > > erzeugt wird, erreicht man auf seiner strecke gut 500kB/s 
> > max. danach 
> > > haben wir die messung wiederholt, aber diesmal auf kanal 
> > 13, immernoch 
> > > ad-hoc und immernoch mit olsr drauf, aber mit der reduktion der 
> > > nachbarn auf einen hat sich der olsr-traffic auf ~5kB/s 
> > reduziert. und 
> > > siehe da, es waren plötzlich 1,4MB/s möglich. tagsüber bricht seine 
> > > erreichbare bandbreite übrigens auf 50-100kB/s und zu guten zeiten 
> > > 200kB/s ein. in der näheren
> > 
> > Wäre es hier vielleicht hilfreich, wenn man multicast Pakete 
> > (oder zumindest die olsr pakete) mit einer etwas höheren rate 
> > zu senden. Das würde dann zwar zu kleineren Zellen führen, 
> > wäre aber in einem Scenario mit hoher Zelldichte wie oben 
> > beschrieben nicht unbedingt von Nachteil. Ich könnte mir 
> > vorstellen, daß manche WLAN-Treiber eine solche konfiguration 
> > per iwpriv erlauben. 
> > Ansonsten könnte vielleicht ein Treiberhack hier helfen (mit 
> > den Treibern auf den WRT54 kenn ich mich da aber zu wenig 
> > aus). So eine Modifizierung wäre auch Abwärtskompatibel zur 
> > Vorhandenen Infrastruktur mit der Ausnahme, daß ff-nodes mit 
> > höherer olsr-paket-rate halt nur für links die auch wirklich 
> > eine hohe Datenrate zu ihren Nachbarn (auch unveränderte) 
> > erlauben einen guten ETX wert aufzeigen würden. 
> > 
> > Ich hatte mal an einem madwifi patch gearbeitet der es 
> > erlaubte die 802.11 PHY datenrate eines zu sendenden 
> > multicast pakets zu kontrollieren. Dies ging in dem der 
> > madwifi treiber kurz vorm überreichen des Pakets an die 
> > hardware einen Blick in die udp payload geworfen hat und bei 
> > Übereinstimmung einer magicnumber die TXdatenrate für das 
> > jeweilige Paket entsprechend eines weiteren feldes in der UDP 
> > payload gesetzt hatte. Es wird wohl keiner Interesse haben 
> > das olsr protocol neu zu etablieren aber für b.a.t.m.a.n. 
> > wäre das vielleicht interessant.
> > 
> > Ciao,
> > ...Axel
> > 
> > _______________________________________________
> > Berlin mailing list
> > Berlin at olsrexperiment.de
> > https://www.olsrexperiment.de/cgi-bin/mailman/listinfo/berlin
> > 
> 
> _______________________________________________
> Berlin mailing list
> Berlin at olsrexperiment.de
> https://www.olsrexperiment.de/cgi-bin/mailman/listinfo/berlin

  _____  

Suchen Sie von einer beliebigen Webseite aus - mit dem perfekten Schutz. Holen Sie sich noch heute die KOSTENLOSE Windows Live Toolbar! Jetzt testen! <http://toolbar.live.com/>  

-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: http://lists.olsrexperiment.de/cgi-bin/mailman/private/berlin/attachments/20061026/d2737d2f/attachment.htm 
-------------- nächster Teil --------------
_______________________________________________
Berlin mailing list
Berlin at olsrexperiment.de
https://www.olsrexperiment.de/cgi-bin/mailman/listinfo/berlin