Über uns
Know-how
FAQ
Projektverlauf
Technikbereich
Ip-Vergabe
Organisation / Termine
Community
Forum
Karte
Gästebuch
Partner
Sonstiges
Downloads
Gallery
Spenden-Topf
Forum Startseite Wiki Karte Forum
WLanhsh & WLanwse Foren-Übersicht WLanhsh & WLanwse
Forum des WLan Hohenschönhausen und des WLan Weißensee
wlanhsh.freifunk.net
 
 FAQFAQ   SuchenSuchen   MitgliederlisteMitgliederliste   BenutzergruppenBenutzergruppen   RegistrierenRegistrieren 
 ProfilProfil   Einloggen, um private Nachrichten zu lesenEinloggen, um private Nachrichten zu lesen   LoginLogin 

Nochmal G-Mode: Helft mit!
Gehe zu Seite Zurück  1, 2
 
Dieses Forum ist gesperrt, du kannst keine Beiträge editieren, schreiben oder beantworten.   Dieses Thema ist gesperrt, du kannst keine Beiträge editieren oder beantworten.    WLanhsh & WLanwse Foren-Übersicht -> WLan Technik
Vorheriges Thema anzeigen :: Nächstes Thema anzeigen  
Autor Nachricht
glockman



Anmeldedatum: 21.09.2004
Beiträge: 2097
Wohnort: suermondtstr/degnerstr ... ohne AP

BeitragVerfasst am: 07.08.2006, 09:06    Titel: Antworten mit Zitat

dein ergebnis ist eher einer der selteneren fälle.

im ad-hoc-meshing-netz erzeugt jeder hop eine doppelte belegung des mediums (erst empfangen, dann senden) und injeziert weiteres packetloss ... es gibt zig beispiele, in denen ein einzelner hops mit mittelmäßigem ETX-wert höhere bandbreiten liefert, als ein zwischenhop mit zwei besseren ETX-werten.

ursache dafür ist der interferenzbereich der APs. RTS und CTS frames werden standardmäßig (vlt mit wl konfigurierbar?) mit 1 oder 2Mb/s gesendet, also mit der rate, welche zur höchsten reichweite führt. das zusammen mit der winzigen größe und der damit verbundenen hohen wahrscheinlichkeit zur erfolgreichen übertragung führt dazu, dass sich tatsächlich mit jedem hop die bandbreite halbiert, da ein AP aus der mitte noch die RTS-anfragen vom ersten empfängt und sendepausen einlegt, ohne von ihm einen nutzdatenstrom empfangen zu können.

die BerlinRoofNet-Leute haben entsprechende messungen unternommen und diese regel ist wissenschaftlich einwandfrei in einer messreihe von mehreren hundert messungen nachgewiesen worden.

fazit: am ende sind wir so schlau wie vorher: probieren ist die devise.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
ropf



Anmeldedatum: 25.04.2006
Beiträge: 582

BeitragVerfasst am: 07.08.2006, 14:55    Titel: Antworten mit Zitat

Auf der Webseite von brn habe ich die Meßreihen nicht gefunden. Was sonst im Internet zu finden ist - ist enorm widersprüchlich.

Das mit der doppelten Belegung stimmt ersteinmal. Aber wenn die Einzelhops 6x schneller sind, ist ein Doppelhop immer noch 3x schneller. Diese Tatsache wird von den ETX-Werten nicht erfaßt.

Außerdem ist der Radius der schnelleren Übertragung kleiner. Wenn bei einer Kette A -> B -> C -> D jeder nur den nächsten Nachbarn erreicht, können A-B und B-C gleichzeitig kommunizieren. Das Paket braucht (vielleicht) länger von A nach C - gleichzeitig können aber wie in einer Pipeline mehrere Pakete unterwegs sein. Also "stille
Post" statt Megaphongebrüll.

Außerdem: Zwei Knoten seien 100m entfernt und damit sei eine Kommunikation mit 24 Mbit möglich. Die RTS/CTS werden aber mit 1Mbit gesendet und reichen (angenommen) 1km weit. Dann hält alles in 1km Reichweite in dieser Zeitt die Klappe - bei gleichmäßiger Knotenverteilung über die Fläche wären das 100 Knoten - und 90 von denen könnten inwischen miteinander reden. Bitte nicht an den Zahlen aufhängen - die habe ich aus der Luft gegriffen.

Die Regel mit der Verdopplung der Übertragungsdauer/Hop als generelle Aussage fechte ich an. Das trifft nur zu, wenn
a) die die Kommunikation über die Kleinen Hops genauso langsam ist wie über den großen
oder b) durch unterschiedliche Reichweiten von Daten- und Managment-Paketen das Medium nicht effizient genutzt wird.

A) trifft in der Regel nicht zu und an B) können wir schrauben

Bei allem was im Deutschen Wissenschaftsbetrieb verzapft wird bin ich zutiefst mißtrauisch - besonders wenn wie bei BRN die Webseite nur ein "Verkaufsprospekt" ist statt Darstellung der Arbeit.

Und deswegen hast Du recht: wir müssen selbst experimentieren. Und meine Oma hat auch recht wenn sie sagt: Nichts ist praktischer als eine gute Theorie.
/ropf
_________________
jabber: ropf at dernico.no-ip.org
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
glockman



Anmeldedatum: 21.09.2004
Beiträge: 2097
Wohnort: suermondtstr/degnerstr ... ohne AP

BeitragVerfasst am: 07.08.2006, 15:19    Titel: Antworten mit Zitat

deine gedankenexperimente sind genau das, was die akademiker so unglaubwürdig macht ... WENN ... DANN ...

nix wenn ... in realität ist nix mit 24MBit los ... einfach weil das medium zu verstopft ist ... 500-700kB/s konstant sind die realität in dicker ad-hoc-luft ... und die kann man schon erreichen wenn man ein mittelmäßiges stück aus dem rauschen ragt. mit nem bissl über rauschen geht ja schon 100-200kB/s. ergo haben die meisten links in dichten meshes eher einen 1/0-charakter ... geht gut oder nicht nutzbar ... das nicht alle diese raten erreichen liegt ja gerade an den multi-hop-verbindungen. dass man mit ad-hoc-meshing trotzdem performant sein kann ist ein illusion, von der wir uns schon verabschiedet haben ... ad-hoc über nicht mehr als 3 hops und dann ab in ein backbone ... eine andere allgemeingültige regel lässt sich kaum aufstellen.

zu der messung in der fakultät adlershof: die benutzen dort atheros-APs bei 100mW sendeleistung, pusten aber alles mit stummeln umher. der aufbau ist über drei etagen und zwei gebäudeteile verteilt. die wlanwellen müssen durch metallbedamftes glas, wordurch teilweise arg asynchrone links entstehen und durch stahlbetondecken. so gibts in diesem aufbau (absichtlich) ein paar ganz miese routen. ganz zu schweigen von den ~130 anderen APs, die im scan so auftauen. alles in allem ein sehr glaubwürdige testumgebung für skalierungstest.

die echten infos zum BRN sind nur in den ihrem wiki zu finden ...
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
ropf



Anmeldedatum: 25.04.2006
Beiträge: 582

BeitragVerfasst am: 07.08.2006, 17:00    Titel: Antworten mit Zitat

Eigentlich geht es hier nur darum, das Netz vom 802.11b-Ballast zu befreien. Die Lösungen für die Zusammenarbeit zwischen B- und G-Geräten sehen für mich schlimmer aus als das Problem.

Leider habe ich die Weisheit NICHT mit Löffeln gefressen. Deswegen stehen meine Gedanken auch nicht in einer Bibel sondern hier im Forum - zur allgemeinen Disskussion.

Das Heraufsetzen der mrate (wl mate xx; xx in Mb/s) ist sicher kein Patentrezept - ich hab es halt probiert und die Ergebnisse berichtet.

Und was den Durchsatz von WLan_Netzwerken angeht, sind die Publikationen im Internet so widersprüchlich das es an Rauschen grenzt. Und zum Berlin Roof Net habe ich einiges zu sagen - aber dazu mache ich einen extra Thread auf.

/ropf
_________________
jabber: ropf at dernico.no-ip.org
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
glockman



Anmeldedatum: 21.09.2004
Beiträge: 2097
Wohnort: suermondtstr/degnerstr ... ohne AP

BeitragVerfasst am: 07.08.2006, 17:54    Titel: Antworten mit Zitat

ich habe genauso wenig wirklich fundierte kenntnisse von dem, was im wlan abgeht, aber es die praxis, mit der ich schon hinreichend konfrontiert wurde. und die besagt nunmal, das zwischenhops im grenzbereich langsamer sind, als direktverbindungen.

in einer sache habe ich den roofnettern übrigens total widersprochen ... sie waren der meinung, dass RTS/CTA mehr kostet, als es bringt ... dann hätten sie den zustand in WSE vor der (zähen) umstellung auf RTS/CTS sehen sollen ...
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
ropf



Anmeldedatum: 25.04.2006
Beiträge: 582

BeitragVerfasst am: 07.08.2006, 20:53    Titel: Antworten mit Zitat

Hier geht es um automatische Bitratenauswahl per packet. http://pdos.lcs.mit.edu/papers/jbicket-ms.pdf
Es werden verschiedene Algorithmen vorgestellt, einschließlich dem in den Atheros-Karten (Onoe). Außerdem jede Menge statistisches Material.

Für mich am frappierendsten: Manchmal arbeiten hohe Bitraten mit weinger Paketloss - und zwischen SNR und packettloss besteht sogut wie kein Zusammenhang.
/ropf
_________________
jabber: ropf at dernico.no-ip.org
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
glockman



Anmeldedatum: 21.09.2004
Beiträge: 2097
Wohnort: suermondtstr/degnerstr ... ohne AP

BeitragVerfasst am: 07.08.2006, 22:02    Titel: Antworten mit Zitat

die atheros nutzen mittlerweile standardmäßig rate_sample ... onoe ist aber immernoch dabei ...
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
ropf



Anmeldedatum: 25.04.2006
Beiträge: 582

BeitragVerfasst am: 08.08.2006, 16:13    Titel: Antworten mit Zitat

Wenn es auch nicht generell so sein mag, so hat doch mein kleines Experiment gezeigt, das Routen über Zwischenhops uU schneller sein KÖNNEN.

Nach Papers des MIT-Roofnetprojektes hängt das wohl von der Knotendichte, den verwendeten Antennen, der Bebauaung, dem Routingprotokoll selbst und vielem anderen ab. Und das dort verwendete Routingprotokoll Srcr bevorzugt wohl kurze Hops.

Der olsrd kann diesen Zusammenhamg schlicht nicht auflösen, da er für Qualitätsberechnungen nur eine (die niedrigste) Bitrate heranzieht. Und DESHALB treffen glockmans Faustregeln zu.

Die MIT-Leute senden zur Routenbewertung Broadcasts mit allen verfügbaren Bitraten und erfassen diesen Zusammenhang sozusagen automatisch. Das ist natürlich um Klassen eleganter als meine manuelle Abschaltung niedriger Bitraten.

Wer sich für Zusammenhänge von packetloss über Distanz, SNR,Bitrate usw interssiert findet hier eine schöne Aufbereiteung von Messergebnissen

/ropf
_________________
jabber: ropf at dernico.no-ip.org
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
ali



Anmeldedatum: 16.01.2006
Beiträge: 369
Wohnort: 13086, Behaimstr.

BeitragVerfasst am: 12.08.2006, 23:41    Titel: Antworten mit Zitat

ali hat Folgendes geschrieben:
Ich schau mal, ob ich die Info, wie gut der Link zu jedem Peer ist (== mit welcher Rate würde das nächste Paket zu diesem Peer geschickt werden) aus den madwifi-ng Treiber herauskriege.


Das ist beim "SampleRate" Modul schon eingebaut:
Code:

cat /proc/net/madwifi/ath1/ratestats_{250,1600,3000}


zeigt die Tabelle der Raten für jeden Peer mit transmission time (tt), perfect transmission time, number of consecutive failed packets, total number of packets, average tries, last tx in jiffies from now. Die Zeile mit dem "*" ist die aktuell gewählte Rate.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden
ropf



Anmeldedatum: 25.04.2006
Beiträge: 582

BeitragVerfasst am: 13.08.2006, 14:49    Titel: Antworten mit Zitat

Siehst Du eine Chance, diese Info auch aus dem Broadcom-Treiber herauszulesen? Hab mal in /proc/net gestöbert aber bis jetzt nichts gefunden.

Gruß ropf
_________________
jabber: ropf at dernico.no-ip.org
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
ali



Anmeldedatum: 16.01.2006
Beiträge: 369
Wohnort: 13086, Behaimstr.

BeitragVerfasst am: 13.08.2006, 14:53    Titel: Antworten mit Zitat

ropf hat Folgendes geschrieben:
Siehst Du eine Chance, diese Info auch aus dem Broadcom-Treiber herauszulesen? Hab mal in /proc/net gestöbert aber bis jetzt nichts gefunden.

Nein, keine Ahnung, ob das geht.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden
glockman



Anmeldedatum: 21.09.2004
Beiträge: 2097
Wohnort: suermondtstr/degnerstr ... ohne AP

BeitragVerfasst am: 14.08.2006, 09:20    Titel: Antworten mit Zitat

ich denke kaum, dass broadcom energie in derartige info-schnittstellen steckt, da otto-normal-konsument diese informationen keum interessieren.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Beiträge der letzten Zeit anzeigen:   
Dieses Forum ist gesperrt, du kannst keine Beiträge editieren, schreiben oder beantworten.   Dieses Thema ist gesperrt, du kannst keine Beiträge editieren oder beantworten.    WLanhsh & WLanwse Foren-Übersicht -> WLan Technik Alle Zeiten sind GMT + 2 Stunden
Gehe zu Seite Zurück  1, 2
Seite 2 von 2

 
Gehe zu:  
Du kannst keine Beiträge in dieses Forum schreiben.
Du kannst auf Beiträge in diesem Forum nicht antworten.
Du kannst deine Beiträge in diesem Forum nicht bearbeiten.
Du kannst deine Beiträge in diesem Forum nicht löschen.
Du kannst an Umfragen in diesem Forum nicht mitmachen.


Powered by phpBB © 2001, 2005 phpBB Group
Deutsche Übersetzung von phpBB.de