Von Verfluchtnochmal-05995bd7b am Mi, 13. Februar 2019 um 17:51 #
Das war vielleicht mal so
sysctl.conf: net.core.default_qdisc = fq_codel
Startup-Script oder ein ohneshot-systemd-unit mit 3 ExecStart= und "wan" halt durch den Namen der phyischen NIC ersetzen
/usr/sbin/tc qdisc add dev wan root handle 1 hfsc default 1 /usr/sbin/tc class add dev wan parent 1: classid 1:1 hfsc sc rate 26Mbit ul rate 26Mbit /usr/sbin/tc qdisc add dev wan parent 1:1 handle 11: fq_codel
In dem Fall ein 250/25 Kabelanschluss, die 26Mbit gibt er in Wahrheit her, bei 27Mbit fängt es zu kippen an sprich bei grossen Uploads steigen Latenzen gewaltig und beginnt Traffic-Loss
Das gleiche auf einer 200/200 Glasfserleitung, in dem Fall wirklich auf 200Mbit und schon gehen die Latenzen auch bei Vollauslastung der Glasfaserleitung und parallelem Traffic nicht mehr über 5ms rauf und wenn man Smokepings auf jeden Hop zum ISP-Backbone laufen hat gibt es auch an keiner Stelle mehr Drops
Bei Anbindungen mit 2 Routern mit HSRP und einem langsameren DSL-Failover auf einer Bridge die 3 gleichen Zeilen für das Interface auf dem DSL hängt mit der entsprechenden Bandbreite
OK, ich habe auf jeden Fall noch vor, das auf tc umzustellen. Ich habe sowas auch schon mal gemacht, nur ist es so lange her, dass ich mich erst mal wieder einarbeiten muss. mod_ratelimit erschien mir jetzt kurzfristig die schnellere Lösung, aber ideal ist sie für diesen Zweck nicht.
Von Verfluchtnochmal-05995bd7b am Do, 14. Februar 2019 um 14:53 #
Es sind tatsächlich nicht mehr als die 3 Kommandos
Funktioniert am Ende insoferne besser weil es den Traffic gleichmässig aufteilt und auch bei Auslastung der Leitung durch mehrere Verbindungen mit hohem Traffic neue Connections und welche die nur wenig Daten übertragen nicht verhungern lässt und vor allem kein Autist ist
Schön bei einem Smokeping zu beobachten, ich hab hier ein paar ins Büro laufen und umgekehrt mit reletiv emfpindlichen Alertgrenzen und ohne "tc" reicht beim Kabelinternet ein rsync einer grossen Datei raus und es hagelt Mails binnen 15 Sekunden
Mit "tc" bleibt die Latenz selbst bei mehreren rsync samt iperf im grünen Bereich und keine Retransmits im Wireshark zu sehen während ansonsten der ISP irgendwo mit seiner Drossel wie vor 1000 jahren anfängt Pakete wegzuschmeissen was der gesamten Qualität nicht gut tut
Und vor allem hat ein Upload wenn sonst keiner was von der Leitung will die volle Bandbreite statt künstlich limitiert zu sein was bei 2 oder 3 ohnehin nicht mehr funktioniert es sei denn das Limit ist so niedrig dass alle 3 zusammen die Leitung nicht überbuchen
Das war vielleicht mal so
sysctl.conf:
net.core.default_qdisc = fq_codel
Startup-Script oder ein ohneshot-systemd-unit mit 3 ExecStart= und "wan" halt durch den Namen der phyischen NIC ersetzen
/usr/sbin/tc qdisc add dev wan root handle 1 hfsc default 1
/usr/sbin/tc class add dev wan parent 1: classid 1:1 hfsc sc rate 26Mbit ul rate 26Mbit
/usr/sbin/tc qdisc add dev wan parent 1:1 handle 11: fq_codel
In dem Fall ein 250/25 Kabelanschluss, die 26Mbit gibt er in Wahrheit her, bei 27Mbit fängt es zu kippen an sprich bei grossen Uploads steigen Latenzen gewaltig und beginnt Traffic-Loss
Das gleiche auf einer 200/200 Glasfserleitung, in dem Fall wirklich auf 200Mbit und schon gehen die Latenzen auch bei Vollauslastung der Glasfaserleitung und parallelem Traffic nicht mehr über 5ms rauf und wenn man Smokepings auf jeden Hop zum ISP-Backbone laufen hat gibt es auch an keiner Stelle mehr Drops
Bei Anbindungen mit 2 Routern mit HSRP und einem langsameren DSL-Failover auf einer Bridge die 3 gleichen Zeilen für das Interface auf dem DSL hängt mit der entsprechenden Bandbreite
OK, ich habe auf jeden Fall noch vor, das auf tc umzustellen. Ich habe sowas auch schon mal gemacht, nur ist es so lange her, dass ich mich erst mal wieder einarbeiten muss. mod_ratelimit erschien mir jetzt kurzfristig die schnellere Lösung, aber ideal ist sie für diesen Zweck nicht.
Es sind tatsächlich nicht mehr als die 3 Kommandos
Funktioniert am Ende insoferne besser weil es den Traffic gleichmässig aufteilt und auch bei Auslastung der Leitung durch mehrere Verbindungen mit hohem Traffic neue Connections und welche die nur wenig Daten übertragen nicht verhungern lässt und vor allem kein Autist ist
Schön bei einem Smokeping zu beobachten, ich hab hier ein paar ins Büro laufen und umgekehrt mit reletiv emfpindlichen Alertgrenzen und ohne "tc" reicht beim Kabelinternet ein rsync einer grossen Datei raus und es hagelt Mails binnen 15 Sekunden
Mit "tc" bleibt die Latenz selbst bei mehreren rsync samt iperf im grünen Bereich und keine Retransmits im Wireshark zu sehen während ansonsten der ISP irgendwo mit seiner Drossel wie vor 1000 jahren anfängt Pakete wegzuschmeissen was der gesamten Qualität nicht gut tut
Und vor allem hat ein Upload wenn sonst keiner was von der Leitung will die volle Bandbreite statt künstlich limitiert zu sein was bei 2 oder 3 ohnehin nicht mehr funktioniert es sei denn das Limit ist so niedrig dass alle 3 zusammen die Leitung nicht überbuchen