[Berlin-wireless] Diskussion: Auto-Portforwarding

[Public Dump]

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