|
|
|
WLanhsh & WLanwse Forum des WLan Hohenschönhausen und des WLan Weißensee wlanhsh.freifunk.net
|
Vorheriges Thema anzeigen :: Nächstes Thema anzeigen |
Autor |
Nachricht |
christoph
Anmeldedatum: 26.07.2005 Beiträge: 23 Wohnort: CharlottenburgerStr. / Ecke Parkst. (IP 104.12.0.8)
|
Verfasst am: 27.09.2005, 19:55 Titel: |
|
|
glockman hat Folgendes geschrieben: | die einzige erklärung wäre gewesen, dass die Framegrößeabfrage vor der fragmentierung passiert ... |
Das hab ich jetzt nicht ganz verstanden...
Ich hab aber nochmal ueber das ganze nachgedacht:
Erstens war mein vorheriges Posting natuerlich ein wenig ungenau: Nicht Layer 3 Packt die Ethernet-Pakete aus. Er bekommt die ausgepackten IP-Pakete von Layer 2 (nur damit ich hier nicht was falsches stehen lasse).
Mein eigentlicher Gedanke war aber:
Falls doch wir und nicht Netgear recht haben (ich weiss, ich masse mir hier einiges an, aber ich kenne Leute, die technische Dokus schreiben...). Also falls bei (RTS=513, Frag=512), RTS nur verwendet wird, wenn das IP-Paket plus WLAN-Header >512 Bytes ist, kann es Sinn machen RTS=513 zu setzen:
Bei RTS muss ja eine Anfrage geschickt werden, ob die Luft nun rein ist ("darf ich senden?"). Also auch ein WLAN-Paket, das die Luft verpestet und ggf. genauso kollidieren kann, wie ein alternativ gesendetes kleines WLAN-Paket, das mein sinnvolles IP-Paket beinhaltet. In beiden Faellen muss das Paket irgendwann nochmal geschickt werden und wenn das RTS-Paket durchkommt, waere auch das IP-Paket durchgekommen.
Eine RTS-Schwelle groesser der Frag-Schwelle ist also sinnvoll, da netto mehr nuetzliche Pakete gesendet werden.
Kurz: Ein WLAN-Paket mit einem sinnvollen (kleinen) IP-Paket ist besser, als eine RTS-Anfrage.
Das ganze gilt natuerlich nur fuer das erste Paket. Fuer das naechste Paket macht RTS dann wieder Sinn. Das Optimum wuerder ich irgendwo zwischen Verhaeltnis Header/Daten und Groesse eines RTS-Pakets suchen.
Oder habe ich hier einen Denkfehler? |
|
Nach oben |
|
|
hok
Anmeldedatum: 28.02.2005 Beiträge: 598 Wohnort: Lindenallee/Meyerbeerstraße
|
Verfasst am: 28.09.2005, 01:13 Titel: |
|
|
glockman hat Folgendes geschrieben: |
@hok: einmal rundmailen bitte
|
Vielleicht noch einen Moment warten, bis Ihr das zuende geklärt habt? Sonst halten mich alle für verrückt - der Überbringer der (bösen) Nachrichten bekommt nämlich immer alles ab
Wieso eigentlich nicht 512/512 - wenn nicht klar ist, ob der Frame incl. oder excl. IP Header und RTS/CTS ist... kann doch nicht falsch sein...(?)
und steigt nicht bei 128 der Overhead exorbitant?
Und wäre es nicht angebracht, den Server auf der 104.13.3.89, der ausgerechnet über die 33 läuft, vorläufig nicht zu betreiben?
hok |
|
Nach oben |
|
|
Adonis01
Anmeldedatum: 21.01.2005 Beiträge: 628 Wohnort: Berlin HSH ( Falkenberger Chaussee )
|
Verfasst am: 28.09.2005, 08:56 Titel: |
|
|
Ich bin der Meinung das man hier viel über die theorie Labern kann, man sollte vieleicht den ein oder anderen Vorschlag einfach mit 1-2 AP`s um die 33 versuchen und dann mal 1-2 Tage beobachten und in einer TOPologie rändern. Die Luft ist ein Medium welches nicht berechenbar ist und wir haben bei berechnungen RTS immer die Faktor X mit drinn welcher auf Grund von Dopplungen und HF-Noise nicht berechnet werden kann. Probieren geht in dem Fall wirklich über studieren. Gruß Markus |
|
Nach oben |
|
|
glockman
Anmeldedatum: 21.09.2004 Beiträge: 2097 Wohnort: suermondtstr/degnerstr ... ohne AP
|
Verfasst am: 28.09.2005, 10:39 Titel: |
|
|
der Beitrag, den marathonmn verlinkt hat, macht gut deutlich, dass die Fragmentierung kaum zur Stabilisierung des Netzes beiträgt ... damit kann lediglich die performance bei relativ starkem paketverlust getuned werden. der Zusammenhang zwischen den beiden Werten ist demzufolde erstmal weniger von bedeutung. Ich war nur die ganze Zeit der Meinung, die Fragmentierungsschwelle muss kleiner als die RTS-Schwelle sein ... zumal es die standardeinstellungen auf dem WRT so vorgeben (siehe konfigurations-screenshots in der techniksection).
als erstes sollten wir einen sinnvollen RTS-wert finden. Da die .33 und die .105 in großem Maße Datenlieferanten sind, habe ich die Fragmentierung sogar deaktiviert, dafür die RTS-Schwelle auf 128byte gesetzt ... so läuft es seit gestern nachmittag.
@hok: maile die 512/128 durch ... damit funktioniert es auf jeden fall ... ob jetzt eine RTS>Frag sinn macht, oder nicht. |
|
Nach oben |
|
|
christoph
Anmeldedatum: 26.07.2005 Beiträge: 23 Wohnort: CharlottenburgerStr. / Ecke Parkst. (IP 104.12.0.8)
|
Verfasst am: 28.09.2005, 10:56 Titel: |
|
|
Hmm... klar machen meine Vermutungen von gestern wenig Sinn, solange es nur wilde Spekulationen sind. Tschuldigung!
Ich finde aber, dass man schon wissen sollte, was man da einstellt und die Auswirkungen zumindest theoretisch verstehen sollte. Sonst kann man die Erkenntnisse aus einem Versuch nur schwer deuten.
(Wie war das mit dem Physiker und dem Beweis, das alle ungeraden Zahlen groesser 1 prim sind? "3-OK, 5-OK, 7-OK, 9-Messfehler, 11-OK, 13-OK, das muss reichen...")
Ich meine naemlich ich haette genau das Gegenteil zu dem gelesen, was hier gestern gepostet wurde. Deswegen hatte ich mich auch eingemischt. Nur leider finde ich es nicht mehr. Ich suche aber nochmal... |
|
Nach oben |
|
|
glockman
Anmeldedatum: 21.09.2004 Beiträge: 2097 Wohnort: suermondtstr/degnerstr ... ohne AP
|
Verfasst am: 28.09.2005, 11:36 Titel: |
|
|
die einzige erklärung, warum RTS>Frag sinn machen könnte:
im rechner wir wirklich ALLES linear abgearbeitet ... also eins nach dem anderen ... so auch der MAC im WLAN-Chipsatz. wenn nun also die abfrage "Hat der Frame mindestens die größe $RTS-Schwelle ?" VOR dem Fragmentierungvorgang erfolgt, würde also ein ethernetframe, der größer als die RTS-schwelle ist, trotzdem ein RTS auslösen. das kann aber nicht funktionieren, da ja der RTS/CTS-Mechanismus auch vereinbarungen zur sendezeit beinhaltet ... wenn der große frame aber in kleinere frames aufgedröselt wird, ist durch mehr overhead mehr sendezeit nötig ... also muss RTS nach der Fragmentierung stattfinden. |
|
Nach oben |
|
|
christoph
Anmeldedatum: 26.07.2005 Beiträge: 23 Wohnort: CharlottenburgerStr. / Ecke Parkst. (IP 104.12.0.8)
|
Verfasst am: 28.09.2005, 13:12 Titel: |
|
|
glockman hat Folgendes geschrieben: |
... wenn der große frame aber in kleinere frames aufgedröselt wird, ist durch mehr overhead mehr sendezeit nötig ... also muss RTS nach der Fragmentierung stattfinden. |
NACK. Wenn man weiss, wie gross der RTS-Overhead ist (ein WLAN-Paket mit RTS-Info ist sicherlich spezifiziert), kann man doch ganz einfach die resultierende WLAN-Paketgroesse (inkl. RTS-Info und Nutzdaten) nach Fragmentierung berechnenen und so entscheiden, ob RTS benutzt werden soll oder nicht. -> Noch nicht ueberzeugt und/oder ich bin zu doof
Aber wie gesagt: Wahrscheinlich bringt die ganze Diskussion wenig, bevor man nicht wirklich weiss, was man einstellt. Kennt nicht jemand irgendwen der mit Sicherheit weiss, ob man mit RTS>Frag RTS generell deaktiviert. Mit Logik kommen wir hier - glaub ich - nicht weiter. Das ist ganz einfach eine Definitionssache. (Bezieht sich die RTS-Schwelle auf die ein- oder ausgebenen Daten auf Layer2? Die geliche Frage ergibt sich dann auch fuer die Frag-Schwelle...)
Oder es geht doch Probieren ueber Studieren: Vielleicht finde ich irgendwann mal Zeit mir die WLAN-Pakete unter verschiedenen Einstellungen anzuschauen (und zu interpretieren...).
Ich hoffe, dass das ganze hier nicht als Prinzipienreiterei meinerseits missverstanden wird. Mich interessiert das einfach und finde es (siehe mein Posting von gestern) generell unsinnig kleine Pakete (<Frag) mit RTS zu senden. Denn wenn das RTS Paket durchkommt, auch das Paket mit den Nutzdaten durchgekommen waere (-> Overhead minimieren). |
|
Nach oben |
|
|
|
|
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
|
| |