Am 17.03.2008, 00:42 Uhr, schrieb tetzlav <[email protected]>:
> aber leider hält sich mittlerweile kaum noch ein NICHT-FREIFUNK-NETZ an > das RTS und quatscht sowieso dazwischen. Der FF-Node würde dann immer > brav auf CTS warten, aber keiner gibt ihm einen Timeslot - daher hatten > wir uns entschlossen das komplett zu deaktivieren... Mh, also rts=2347, wie es in der aktuellen Testversion standardmäßig eingestellt ist, halte ich aus folgenden Gründen für gefährlich: 1. Sicher halten sich die wenigsten APs an RTS/CTS doch wenn ich davon ausgehe, dass gerade in Connewitz FF recht flächendeckend das Medium beansprucht, käme es ohne RTS zu massenweisem "Paketsterben". Und die wenigsten APs in Gebäuden verursachen so weitreichende "Störungen" wie die FF-Router mit ihren Antennen auf den Dächern. 2. Wie im Test bereits begründet, ist es ja nicht nur eine Sache zwischen FF und anderen Netzen, sondern auch ein internes Problem. Wenn jeder FF-Router in einem dicht besetzten Gebiet einfach drauflossendet ohne sich mit seinen Nachbarn abzusprechen, wird die Paketankunft zum Glücksspiel. Ich denke RTS=250 oder 500 sind so verkehrt nicht. zudem muss ich björn zustimmen: Am 17.03.2008, 07:05 Uhr, schrieb Björn <[email protected]>: > ohne mir den test angeschaut zu haben, mir fällt gerade ein, ein rts in > kombination mit frameburst kann sowieso nicht schaden, da eine sendezeit > für mehrere datenpakete reserviert wird. Wenn nach dem Update auf die neue Version die Verbindungsgeschwindigkeiten imens einbrechen, wissen wir, wo der Fehler liegt. Wie gesagt, das Phänomen tritt erst auf, wenn mehr als zwei Stationen an der Kommunikation beteiligt sind. -- 118.2 _______________________________________________ freifunk-leipzig mailing list [email protected] https://lists.subsignal.org/mailman/listinfo/freifunk-leipzig
