RTS/CTS-Schwellen PDF Drucken E-Mail
Geschrieben von halfmoon ( Robert )   
Montag, 18. September 2006
Eine Erklärung zum Sinn von RTS / CTS und warum diese Werte auf jeden Fall in der Firmware gesetzt werden sollten.

Nach einigem Probieren und nun schon einigen Erfahrungswerten sind wir bei den Werten 500 fuer Frag-Schwelle und 250 fuer RTS-Schwelle als problemlose Werte angekommen. Da einige aber immernoch nicht die Wichtigkeit dieser Parameter erkennen, hier noch einmal eine Erklaerung:

Zur Veranschaulichung der Angelegenheit, hier ein Bild:

rts-schema

 

 

 

 

 

 

 

 

 

 

Es stellt 5 APs dar ... b,c,d und e koennen a empfangen, sehen sich gegenseitig aber nicht (keine Ueberlappungen der Kreise). dadurch, dass sich die aeusseren APs nicht empfangen, weiss auch keiner vom anderen, ob er sendet (ausser a ... der weiss Bescheid). In dieser Situation redet man von hidden nodes (verborgene Knoten) ... also b ist zb. ein hidden node fuer c, d und e. Sendet jetzt b und c moechte auch etwas loswerden, dann funken 2 APs auf a ein ... da die Daten nicht auseinandergehalten werden koennen, schlaegt die Uebertragung fehl ... beide APs versuchen wieder zeitgleich das Datenpaket erneut zu uebertragen ... auch der Versuch schlaegt fehl ... irgendwann hat sich ein AP durchgesetzt (vielleicht durch eine hoehere zur Verfuegung stehende Bandbreite) und das Spiel geht von vorne los. das Problem bei der Sache ist, dass nicht nur die beiden APs davon betroffen sind, sondern AP a nur noch damit beschaeftigt ist, dem Datenmuell dieser APs zuzuhoeren, ohne effektiv Daten zu befoerdern. um diesem Problem herr zu werden, kommt RTS/CTS (Ready-To-Send / Clear-To-Send) zum Einsatz. Will ein AP seine Daten verschicken, gibt er dem Empfaenger-AP durch ein RTS ueber eine wartende Sendung und ihre groesse Bescheid. daraufhin reserviert der Empfaenger-AP Sendezeit fuer den Sender-AP und schickt ihm die Bestaetigung zum Senden, das CTS ... alle anderen APs muessen nun warten die Transmission beginnt. Die RTS-Schwelle gibt an, ab welcher Datenmenge Sendezeit reserviert werden soll.

Standardmaessig ist RTS/CTS durch einen RTS-Threshold weit oberhalb der maximalen Ethernet-framegrösse (1500byte) deaktiviert, da davon ausgegangen wird, dass sich alle Teilnehmer an einem AP gegenseitig empfangen koennen ... es muss also ein Wert unterhalb 1500Byte gesetzt werden ... fuer uns 250byte.

Das ganze wird bei deaktiviertem RTS/CTS durch das Verhalten von TCP/IP noch weiter verschlimmert ... fuer jeden Schwung Pakete (auch window genannt) wird der korrekte Empfang mit einem Bestaetigungspacket (ACK-Acknowledgment packet) beantwortet. Geht dieses sehr kleine Paket (unter 64byte) verloren, dann geht der Sender davon aus, dass die Pakete nicht angekommen sind und schickt sie ein weiteres mal ... verbraucht also ein zweites mal Bandbreite fuer ein und die selben Daten. Zusaetzlich wird bei jedem Fehler das window extrem verkleinert ... d.h., dass die Anzahl an Datenpacketen, die mit einem ACK-packet bestaetigt werden können, extrem abnimmt. Da die Uebertragung des folgenden windows erst startet, wenn das ACK fuer den letzten Schwung angekommen ist, entstehen Wartezeiten, die effektiv die Bandbreite senken, was bei Downloads gut beobachtet werden kann. Um nochmal zu unterstreichen, dass hier nicht von einem hypothetischen fall die Rede ist. 

Natuerlich hat dieses Verfahren ein riesen Manko ... wie so vieles im Leben ... es reduziert  die maximal erreichbare Bandbreite, weil viele Latenzen beim Austausch der RTS und CTS anfallen.

Da die wlan-karte nach jedem Frame kurz in den Äther horcht, ob woanders auch noch Resourcen gebraucht werden, können leichter kleine http- oder dns-Anfragen zwischen die grossen Datenmengen geschoben werden, wenn wir die Fragmentation-Schwelle senken ... das wlannetz wirkt reaktionsfreudiger. Ganz nebenbei ist die Wahrscheinlichkeit zur erfolgreichen Uebertragung eines kleinen Frames groesser, als die eines grossen Frames, was die Anzahl der Neuübertragungen senkt. Zur Wahrung einer gewissen Qualitaet des wlan-netzes, sollten alle, die Gebieten mit hoher Knotendichte ihrenAP betreiben, die Fragmentation gesetzt haben, vorzugsweise auf 500byte oder etwas in der naehe gehen. Der optimale Wert kann nur durchs Experimentieren gefunden werden.

 Ergänzung: Bei eigenen Experimenten ist zu beachten, daß die Ergebnisse nicht nur von den eigenen Einstellungen, sondern auch von denen der Nachbarn abhängen - und von deren Aktivität. Für ein realistischs Meßszenario nach der obigen Grafik würde man gleichzeitig Endlosdownloads von C nach D und von B nach E laufen lassen, während man auf A den durchsatz mißt.

Letzte Aktualisierung ( Dienstag, 21. November 2006 )
 
< zurück   weiter >
Technik
Antennen
Router
Firmware
Bastelbereich
Software
Hardware-APs
Sonstige Netzwerktechnik
Hardware
/7\Bytecamp
Bookmark and Share

Freifunk Berlin Nordost ist eine nicht kommerzielle Webseite.
Creative Commons License
Dieser Inhalt ist unter einer Creative Commons-Lizenz lizenziert.