[Berlin-wireless] Bandbreite per cronjob ändern?

[Malte]

On Sat, 16 Jan 2016, Holger wrote:

> Ich komme mal wieder hierauf zurück, weil das Abschalten von qos einfach den 
> asymmetrischen DSL-Anschluß zu einem symmetrischen Anschluß (auf 
> upload-Bandbreite) macht. Das qos sorgt dafür, daß ack-Pakete pfeilschnell 
> durchgeleitet werden und es weiter asymmetrisch sein kann.

Entweder habe ich Dich falsch verstanden, oder Du hast die ACK-Thematik 
was Upload angeht falsch eingeordnet.

Das Problem bei asymmetrischem DSL ist, dass es bei gleichzeitigem Up- und 
Download des Teilnehmers vorkommen kann, dass die ACK-Pakete für 
eingehende Daten im Download mit den Daten im Upload konkurrieren und 
evtl. so lange verzögert werden (oder ganz wegfallen), dass die 
Download-Geschwindigkeit darunter leidet, obwohl noch genug 
Download-Bandbreite verfügbar wäre.

Schaltet man die Bevorzugung von ACK-Paketen im Upstream ab (eben z.B. QoS 
ganz aus), kann es eben vorkommen, dass Downloads leiden, wenn 
gleichzeitig Uploads stattfinden. Mit "symmetrisch" hat das aber nichts zu 
tun, und in der Praxis spielt das auch kaum eine Rolle, solange nicht 
jemand Peer To Peer macht (was den Upstream schnell dicht macht).

> Es [3] gab ja mal weitere Überlegungen dazu, was ist daraus geworden?

Da ging es eigentlich um was ganz anderes...

> Also lautet der Bürozeitentext:
> drosselung ab 8 Uhr aktivieren:

Ich hatte in
http://lists.berlin.freifunk.net/pipermail/berlin/2016-January/031489.html
beschrieben, wie man es so einrichten kann, dass Freifunk einfach 
gegenüber dem lokalen/privaten Traffic nachrangig behandelt wird. Damit 
spart man sich dann cronjobs und gibt Freifunk immer so viel Bandbreite 
wie möglich, ohne lokalen Traffic zu stören.

Die ACK-Priorisierung für lokal macht bei der Lösung der DSL-Router; die 
für Freifunk der Freifunk-Router, sofern man QoS dort anlässt (unter 
Angabe der DSL-Bandbreite). Wobei QoS bis inkl. Kathleen 0.1.2 sowieso in 
der Hinsicht kaputt ist, weil es nur die OpenVPN-UDP-Pakete sieht, nicht 
die darin gekapselten TCP-Verbindungen, und dementsprechend auch keine 
ACK-Priorisierung machen kann. Daran, dass das lange niemandem aufgefallen 
war, sieht man, wie "wichtig" das in der Praxis im Zusammenspiel mit 
anderen Performance-Engpässen wie OpenVPN etc. ist. ;-)

Grüße,
Malte

> [3] https://github.com/freifunk-berlin/firmware/issues/94