[Wien] Upload vs Download

[Henning Rogge]

2015-04-13 0:42 GMT+02:00 Erich N. Pekarek <(spam-protected)>:
>
> Hallo!
>
> Am 2015-04-12 um 21:55 schrieb (spam-protected):
>
> Hallo Leute!
>
> Also für Upload schlechter als Download fallen mir 2 mögliche Ursachen ein.
>
> 1.) Irgendwo entlang der Route hört die (weiter von dir entfernte) Gegenstelle schlechter als die näher bei dir liegende. Dadurch brauchen Daten die von dir weg geschickt werden (Upload) im Durchschnitt mehr Retries als in die andere Richtung --> geringerer Durchsatz <-- ich bin mir nicht sicher ob Gerhard mit seinem 1. Grund das selbe gemeint hat.
>
> Die von OLSR errechneten asymmetrischen Routen sind nicht auf Geschwindigkeit, sondern auf Übertragungsverlässlichkeit hin optimiert.
> Bridges können diese Werte verfälschen.
> Eine LQ von 1.000 oder NLQ von 1.000 bekommt somit wohl den Vorzug.

Bevor jemand fragt... erst die Olsrd2 Implementierung nutzt auch die
Link-Geschwindigkeit für die Kosten eines Links.

> 2.) Der selbe wie Gerhards Grund Nr. 2 (Traffic geht durch assymetrischen Tunnel)

Evenfalls ein Unterschied zum Olsrd2... Olsrd rechnet immer
symmetrische Kosten aus für alle Links, Olsrd2 rechnet mit gerichteten
Kosten, was heißt das ein asymmetrischer Link auch asymmetrisch
genutzt wird.

> 3. WLAN-Spezifika: Im Adhoc-Mode kommt es zum -ich nenne das jetzt absichtlich falsch- "Übersprechen", wenn "Hidden Stations" vorhanden sind.
> Ich habe einmal irgendwo gelesen (Presseankündigung für ein Alternatives Verfahren vor zwei Jahren?) Access Points sind hinsichtlich Ihrer Timeslots eher auf Download hin optimiert, nicht auf Upload. D.h. bei starkt ausgelasteten APs kann es Engpässe geben.
>
> 3.1 RTS/CTS muss nicht unbedingt auf beiden Seiten identisch konfiguriert sein und ist womöglich auch nicht immer optimal eingestellt.

RTS/CTS kann unter umständen einen enormen Vorteil bringen... wir
haben am Institut Reproduzierbar eine Verbindung gehabt die dank
Hidden Station keine Multicast-Pakete mehr übertragen könnte... aber
Unicast mit 24 MBit/s.

Henning Rogge