[Berlin-wireless] Bandbreite per cronjob ändern?

[Holger]

Moin Malte,

Am 19.01.2016 um 12:44 schrieb Malte:
>> 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.

Ja ich dachte sie gehen im upload unter, es ist der download wo sie 
verschütt gehen.

> 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).

Ja, Sven und ich haben uns darauf geeinigt, daß das Problem 
wissenschaftlich nachweisbar ist und praktisch keine Rolle spielt.
Hab in den letzten Tagen ff-Router mit gleichzeitigen up- und downloads 
getreten und in den realtime graphs qualifiziert geschätzt, daß mit qos 
etwas mehr up and down transportiert wird aber auf keinen Fall der 
download auf upload Bandbreite reduziert wird.
Was mich zu der Einschätzung bringt, daß es schon prima ist qos mit 
realen Werten anzuhaben aber abgeschaltet nicht ganz fatale Folgen hat.

>> Es [3] gab ja mal weitere Überlegungen dazu, was ist daraus geworden?
>
> Da ging es eigentlich um was ganz anderes...

Ah ja, ich hatte es so verstanden, daß da die Anschlußbandbreite und der 
ff-freigegebene Anteil als Basis für qos eingegeben wird.

Was ich für sinnvoll halte, weil der qos-Kram nur vernünftig 
funktioniert, wenn die verfügbare Bandbreite stimmt. Da werden queues 
und discs definiert, die von der verfügbaren Bandbreite abhängen, nehme 
ich nach dem allgemeinen Modell an, weiß aber nicht ob es hier auch so 
läuft, da es nicht dokumentiert ist.
Ist das nicht stimmig, kippen niederpriorisierte Pakete einfach ab, weil 
die physische Bandbreite erreicht ist und qos nur noch Fingerübungen macht.

>> 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.

Ja eine schöne Möglichkeit, wobei ich nicht unbedingt am Router eines 
Betreibers rumkonfigurieren möchte.

> 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. ;-)

Ja :D akademische Erkenntnisse vs. harte Wirklichkeit!

Wobei meine Meinung ist, daß qos schon schöne Ergebnisse zeigen kann, 
vielleicht wäre es wichtiger, die aktuelle vpn-Bandbreite dem router-qos 
mitzuteilen, was dann entsprechend priorisiert.

Ok, wenn's nur die OpenVPN-UDP-Pakete sieht, i.e. alle Pakete sehen 
gleich aus, kann das Abschalten Speicher und CPU sparen?


Lieben Gruß
Holger

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