[Berlin-wireless] Vorschlag: Basic-Rate! Für eine sauberere Luft! (war: Vorschlag: SSID nur senden, wenn Internet verfügbar)

Matthias Mehldau wetter at netzpolitik.org
Di Jul 12 10:08:28 CEST 2016


Juten Tach!

Ich hab da auch noch so ne Anregung für default-config Parameter:

	Erzwingen von minimalen Datenraten

Folgendes zehrt primär aus meinen beruflichen Erfahrungen mit
hoch-dichten Umgebungen und ist für alle Winkel, die "nicht so gut
ausgeleuchtet" sind, hilfreich.

On 07/09/2016 01:42 PM, Max wrote:
>  Ich vermute, dass es oft daran liegt, dass mein Smartphone zwar das Signal des Routers sieht, umgekehrt jedoch nicht.

Ein sehr beliebter State von "funktional kaputt".

Ebenfalls sorgt dieser Umstand auch gerne für das Phänomen "kein DHCP",
da es sich dabei um Broadcast-Traffic handelt, welcher ja nur mit der
Bitrate des Clients mit dem schlechtesten Empfang ausgestrahlt werden
kann. Das führt bei viel Broadcast-Traffic und einem Client mit brutto 1
MBits/s dazu, dass nur diese Menge an Broadcast-Traffic durch-, also
auch häufiger mal kein DHCP-response zurück-kommt.

Mit den Parametern "basic_rate" habe ich gute Erfahrungen machen können, um

- Clients mit zu schlechtem Empfang frühzeitig zu droppen
- Clients, welche auf einem anderen AP besser "aufgehoben" wären zu
diesem zu stubsen
- somit einen besseren Durchsatz in einer Zelle zu erzielen ("sauberere
Luft dank weniger re-transmissions" (teuer! Es gibt nur eine Zeit für
alle.))

Alles in allem halte ich diese Strategie für sehr sehr angebracht, grade
in so Straßenschluchten und Umgebungen, in denen viele andere APs funken.

Salopp gesprochen heisst es dann seitens des APs: "Entweder kannste gut
mitreden, oder halt nicht."

Technisch wird dies so gelöst, dass nur ein bestimmter Satz an Raten in
den Beacon-Frames announced wird, aka a "Du kannst mit mir nur mit den
folgenden Modulationen sprechen".

Ein anderer Mechanismus, der zumeist ähnliche Auswirkungen hat, nennt
sich "minimum RSSI"; hier bei wird ein mindest Signal-Rausch-Abstand
seitens des Accesspoints vorausgesetzt, ehe dieser mit dem Client
"spricht". (Das halte ich nicht für ganz so elegant, da weiterhin ein
Client auf 1 MBits/s verhandeln darf.) Die MinRSSI-Strategie ist
allerdings in OpenWRT auch m.W.n. nicht implentiert.

Zu bestimmen ist dabei die Rate, welche vorausgesetzt wird. Hierfür
sollte ein vernünftiger, nicht zu hoher, Pauschalwert gefunden werden.
Jedes Setup sollte dahingehend getestet werden welche Bitrate an einer
noch abgedeckt gewusst gewollten Stelle auch mit einer kleinen Antenne
(Smartphone) noch erfolgreich verhandelt wird. (Lautet sie 1 MBits/s,
ist die Positionierung des APs vmtl. fragwürdig ;)

Ich habe häufig mit 12 MBits/s gearbeitet. Vermutlich kann mensch in
vielen Umgebungen auch gut und gerne höher ansetzen.

Es gab auch mal den Paramter "supported_rate", welcher allerdings heute
in der Doku zu /etc/config/wireless nicht mehr zu finden ist. Ferner ist
in diesem Zusammenhang natürlich der Paramter "mcast_rate" (Multicast)
interessant, mit welchem ich allerdings nicht experimentierte. (Wird
technisch Broadcast-Traffic nicht auch häufig als eine Form des
Multicast-Traffics gewertet?)

Die magischen, intensiv erprobten Zeilen des Config-Files lauteten im
Nano-M-Setup:

	option "basic_rate" "12000"
	option "supported_rate" "12000 18000 24000 36000 48000 54000"

Unklar ist mir hingegeben ob und wie gut diese Paramter im ad_hoc Modus
genutzt werden.

Mit bestem Gruß,
wetterfrosch



Mehr Informationen über die Mailingliste Berlin