[Berlin-wireless] Tempo Tempo

[Rolf Pfeiffer]

Lassen wir mal den ewigen Grundlagenstreit beiseite. Es ist klar, daß RTS/CTS 
Performance kostet, aber die Funktion des Netzes (nicht nur eines Links) 
unter gestörten Bedingungen ermöglichen soll

Ich bin gern bereit zu glauben, daß das nicht immer so funktioniert, auch wenn 
es in Pankow wie im Bilderbuch geklappt hat.

Ich will auf folgendes hinaus: für eine aussagefähige Messung reicht es NICHT, 
einen einzelnen Link zu betrachten, sondern es geht um die Wechselwirkung von 
mehreren Links.

Meine "Überkreuz-Messung" war ein erster naiver Schritt in diese Richtung. 
Aber was wir wirklich brauchen, ist ein MAß für den NETZWERKDURCHSATZ. Bis 
jetzt haben wir aber nicht einmal eine DEFINITION dafür. Und hier erhoffe ich 
mir mal echte Hilfe von unseren "pöhsen Akademikern"

Da wir schonmal bei Grundlagen sind, hol ich gleich noch weiter aus. Grob 
eingeteilt können wir Paketverluste folgenden Ursachen zuschreiben:

a) zu geringes SNR bezogen auf Modulation und Bitrate
b) Interferenz (zB mit Mikrowellen)
c) Paket-Kollisionen

Gegen a) hilft eine kleinere Bitrate, und darauf heben die meisten 
Bitratenautomatiken ab: Zuviel Packetloss->runter mit der Bitrate.
Gegen b) hilft ein Elektroschocker (Scherz!).
Gegen c) helfen zeitlich kurze Pakete (kleiner Frag-Wert + hohe Bitrate)

Nun kann der Treiber aber nur feststellen, DASS ein Paket kaputt ist - nicht 
WARUM. Er fährt also brav die Bitrate runter und macht uns robuster gegen 
Rauschen.

Nun dauert aber ein Paket gleicher Größe DOPPELT so lange (die Bitraten sind 
etwa 2:1 gestaffelt) - und damit steigt widerum die 
Kollisionswarscheinlichkeit. Wir kommen also vom Regen in die Traufe!

Besser wäre es, wenn bei Änderung der Bitrate die Fragmentgröße entsprechend 
geändert würde - die Dauer bliebe konstant - und es würde in dieser Richtung 
wenigstens nicht schlechter.

Machen diese Gedanken nun Sinn? Sieht sich jemand in der Lage, einen Treiber 
entsprechend zu hacken, wenigstens für Testzwecke?

Gruß Rolf