ubuntuusers.de

Hallo zusammen,

aus einem ursprünglichen einfachen statischen Setzen von initcwnd und initrwnd ist inzwischen ein kleines Dispatcher‑Script geworden. Ziel ist, TCP‑Performance und Latenz automatisch zu verbessern (interface‑adaptives initcwnd/initrwnd, BBR, CAKE qdisc, RAM‑adaptive Buffer, IPv4/IPv6 Smart‑Routing mit DHCP‑Fallback).

Ich habe das Script auf Github veröffentlich und bitte um Tests und Feedback.

Projekt: https://github.com/Mylinde/linux-network-optimizer

Changelog: https://github.com/Mylinde/linux-network-optimizer/blob/main/CHANGELOG.md

Ausprobiert. Kubuntu Questing Quokka auf dickem altem Recheneisen, nicht mobil, an stationärem Router.

Vorher:

default via 192.168.0.1 dev enp0s25 proto dhcp src 192.168.0.7 metric 100 
qdisc fq_codel 0: root refcnt 2 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64 

Nachher:

default via 192.168.0.1 dev enp0s25 proto dhcp src 192.168.0.7 metric 100 
default via 192.168.0.1 dev enp0s25 proto static src 192.168.0.7 metric 500 initcwnd 40 initrwnd 60 
qdisc cake 8001: root refcnt 2 bandwidth unlimited diffserv3 triple-isolate nonat nowash no-ack-filter split-gso rtt 100ms raw overhead 0

Nun brauche ich aber kein Wlan, und für wechselnde Standorte ist mein altes Heavy Metall Recheneisen viel zu schwer. So, dass sich wieder zurück bin auf das alleinige dhcp Routing. Und vorläufig auch auf qdisc fq_codel zurück. Muss erst mal etwas weiter lesen über das qdisc cake 8001. Konnte jedenfalls für mich zunächst noch keinen Vorteil erkennen. Aber der Internetzugang funktionierte weiterhin, was schon mal gut ist. 👍

Einen Vorschlag hätte ich aber für install.sh

• https://github.com/Mylinde/linux-network-optimizer/blob/main/install.sh#L48

Anstatt:

cp netopt /etc/NetworkManager/dispatcher.d/99-netopt
chmod +x /etc/NetworkManager/dispatcher.d/99-netopt

... ließe sich auch install verwenden:

install -v -m 755 -p netopt /etc/NetworkManager/dispatcher.d/99-netopt

Nachtrag: Mein Kernel ist übrigens ein XanMod Kernel, aber auch zuvor hatte ich schon sysctl Einträge für TCP congestion BBR, und auch für qdisc.

@trollsportverein

Danke, für die Anmerkung ist korrigiert.

Eine Erklärung zum Script nachgereicht.

Das Script ändert automatisch Netzwerkparameter sobald sich ein Interface verbindet oder DHCP-Einstellungen sich ändern. Es integriert sich in den NetworkManager (Dispatcher) und passt Routing, TCP-Parameter, QoS und Puffergrößen dynamisch an – basierend auf Interface-Typ, verfügbarer RAM‑Menge und gemessener Latenz (RTT).

Das tut das Script.

• Priorisiert Verkehr intelligent (QoS) mit CAKE und DSCP-Markierung (nftables).

• Wählt automatisch den optimalen TCP Congestion Control Algorithmus (BBR oder CUBIC).

• Beschleunigt Verbindungsaufbau durch angepasste TCP-Startfenster (initcwnd/initrwnd).

• Optimiert IPv4/IPv6-Routen mit Dual-Route-Failover (static metric 500, DHCP metric 600).

• Passt TCP-Puffergrößen an verfügbaren RAM und RTT an, reduziert Bufferbloat.

• Funktioniert robust bei DHCP‑Erneuerungen und Interface‑Wechseln.

Was passiert technisch?

• Ereignisgesteuert über NetworkManager

• Das Skript reagiert auf die Events up, dhcp4-change und dhcp6-change.

• Nutzung eines Lockfiles, damit pro Interface immer nur eine Instanz läuft.

• Bei down/pre-down räumt es auf (QoS-Tabellen werden entfernt).

• RTT-Messung und Interface-Erkennung

• Misst RTT bevorzugt aus bestehenden TCP-Verbindungen via ss; fällt nur bei Bedarf auf ping zum Gateway zurück.

• Erkennt den Interface-Typ (z. B. ethernet, wifi, vpn) und wählt darauf basierend Parameter aus.

TCP-Optimierungen

• TCP Fast Start: initcwnd/initrwnd werden je nach Interface gesetzt (z. B. 40/60 für Ethernet, 30/40 für WiFi, 20/30 für VPN/Mobil).

• tcp_fin_timeout wird je nach Interface (3s/5s/10s) bzw. RTT berechnet.

• Schaltet sinnvolle Defaults: tcp_slow_start_after_idle=0, tcp_notsent_lowat=131072, tcp_tw_reuse=1, tcp_adv_win_scale=-2, tcp_collapse_max_bytes=6291456.

• Congestion Control: Automatische Auswahl zwischen BBR (bei niedriger/konstanter Latenz) und CUBIC (bei höherer/veränderlicher Latenz; bevorzugt für VPN/Mobil/ältere WiFi-Standards).

• ECN: Aktiviert ECN=1 auf den meisten Interfaces bzw. respektiert vorhandene Kernel-Voreinstellungen (z. B. ECN=2 bei XanMod).

• CAKE Queueing mit Diffserv

• Setzt CAKE als Standard-QDisc (net.core.default_qdisc=cake) und konfiguriert diffserv4.

• Reduziert Bufferbloat und ordnet Verkehr in Prioritätsklassen ein.

• QoS via nftables (DSCP-Markierung)

• Legt pro Interface eine eigene nftables-Tabelle an (inet/netopt_<interface>).

• Definiert Port-Sets (Voice/VoIP, Interactive, Video, Web, Bulk/P2P) und markiert Verkehr bidirektional mit passenden DSCP-Werten: EF (VoIP/Voice), CS6 (DNS/NTP), AF41 (SSH/RDP), AF31 (Video), AF11 (Web/FTP), CS1 (Bulk/P2P).

• CAKE liest diese DSCP-Werte und priorisiert entsprechend.

• Falls nftables nicht vorhanden ist, läuft das Skript trotzdem (nur ohne automatische DSCP-Markierung).

• Routing-Strategie mit Failover

• IPv4/IPv6: Erstellt optimierte statische Default-Routen mit niedrigerem Metrik-Wert (500) und lässt DHCP‑Routen als Fallback (600) bestehen.

• IPv6: Validiert Gateways (Link-Local und Global Unicast), setzt „pref high“ und wählt eine passende Source-Adresse, wenn verfügbar.

• RAM‑adaptive TCP-Puffer

• Berechnet rmem_max/wmem_max und tcp_rmem/tcp_wmem aus RAM‑Größe und RTT‑Klassen.

• Vermeidet überdimensionierte Puffer bei hoher RTT, reduziert Latenzspitzen.

Was soll das bewirken?

• Spürbar schnellere Verbindungsaufnahme (30–50% für kleine Transfers).

• Deutlich weniger Latenzspitzen unter Last (CAKE + ECN + angepasste Puffer).

• Bessere Interaktivität (SSH/RDP) und VoIP‑Qualität dank DSCP/CAKE‑Priorisierung.

• Robustes Verhalten bei DHCP‑Erneuerungen und Interfacewechseln.

Voraussetzungen:

• NetworkManager aktiv, iproute2 (ip/ss/tc) und bc installiert.

• Kernel mit CAKE‑Support (ab Linux 4.19).

• Optional, empfohlen: nftables für QoS‑Markierung.

• Funktioniert besonders gut mit latenzoptimierten Kerneln (z. B. XanMod, Liquorix, CachyOS).

Hinweise:

• Das Skript ändert Systemnetzwerkparameter; Einsatz auf eigene Verantwortung. Vor produktivem Einsatz testen.

• Deinstallation über uninstall.sh oder manuelles Entfernen der Dispatcher‑Datei; NetworkManager danach neu starten.

• CAKE/QoS lassen sich sofort entfernen (tc qdisc del dev <iface> root); TCP‑Defaults greifen nach Neustart wieder.

• Manche ISPs ignorieren oder entfernen DSCP‑Markierungen; die CAKE‑Verbesserungen greifen dennoch lokal.

• BBR ist nicht auf allen Kerneln verfügbar; das Skript fällt automatisch auf CUBIC oder Reno zurück.

• Bei sehr hoher RTT werden Puffer absichtlich konservativ konfiguriert, um Latenz zu senken.

Für wen ist das sinnvoll?

• Für Anwender, die Latenz, Interaktivität und Stabilität verbessern wollen – z. B. Gaming/VoIP, Remote‑Work (SSH/RDP), stark ausgelastete Links.

• Für Systeme mit wechselnden Interfaces (WLAN/Ethernet/VPN), bei denen automatische, robuste Optimierung wichtig ist.

Interessant, wie könnte man das testen, also zum Beispiel mit einem Vergleich von Werten - vorher/nachher? Kann der Einsatz des Scriptes auch in virtualisierten Systemen sinnvoll sein?

@verdoft

Ich habe dem Projekt ein Script zum Testen hinzugefügt, selbst einen Test durchgeführt und das Testergebnis im Repo abgelegt. Das Test-Script führt folgende Test durch:

Metrik:	                  Was wird getestet:	                   Zeigt Wirkung von:
Ping Idle	        RTT ohne Netzwerklast (20 Pakete)	TCP-Parameter, BBR
Latency Under Load	RTT während 100MB Download	        CAKE qdisc (Bufferbloat-Kontrolle)
Page TTFB	        Time To First Byte (3 Websites)	        initcwnd=40 (TCP Fast Open)
Page Load Total	        Komplette Ladezeit (3 Websites)	        Kombinierte Optimierungen

Seiten/URL's die für den Test kontaktiert werden:

Ping:
google.com

Ladezeiten:
amazon.com, ebay.com, wikipedia.org

Downloadlast wird erzeugt durch/mit:
http://speedtest.tele2.net/100MB.zip

mein Testergebnis:

mario@mario-Vivobook ~/G/l/Test > doas ./netopt-test
doas (mario@mario-Vivobook) password: 
╔═══════════════════════════════════════════════════════════╗
║  Network Optimizer - Performance Benchmark                ║
╚═══════════════════════════════════════════════════════════╝

═══════════════════════════════════════════════════════════
 PHASE 1: WITHOUT NETWORK OPTIMIZER
═══════════════════════════════════════════════════════════

Current qdisc: qdisc noqueue 0: root refcnt 2 

→ Measuring ping latency (20 packets)...
  Average RTT: 63.347ms

→ Measuring latency under load...
  Measuring latency during active download...
  Latency under load: 35.214ms

→ Measuring page load times...
  Testing: https://www.amazon.com
    TTFB: 273.145000ms, Total: 274.060000ms
  Testing: https://www.ebay.com
    TTFB: 533.340000ms, Total: 1234.395000ms
  Testing: https://www.wikipedia.org
    TTFB: 341.624000ms, Total: 584.461000ms
  Average TTFB: 382.70ms (3/3 successful)
  Average Load Time: 697.63ms (3/3 successful)

✓ Phase 1 completed

Please install and apply netopt now:
  sudo ./install.sh
  sudo nmcli connection down <connection-name>
  sudo nmcli connection up <connection-name>

Press Enter when netopt is active and network is reconnected...

═══════════════════════════════════════════════════════════
 PHASE 2: WITH NETWORK OPTIMIZER
═══════════════════════════════════════════════════════════

Verifying applied optimizations:
  ✓ CAKE qdisc: Active
  ✓ Routes: 2 (static + DHCP fallback)
  ✓ Congestion Control: bbr
  ✓ tcp_slow_start_after_idle: 0 (optimized)
  ✓ nftables QoS: Active

Press Enter to start Phase 2 tests...

→ Measuring ping latency (20 packets)...
  Average RTT: 36.638ms

→ Measuring latency under load...
  Measuring latency during active download...
  Latency under load: 31.251ms

→ Measuring page load times...
  Testing: https://www.amazon.com
    TTFB: 252.602000ms, Total: 253.733000ms
  Testing: https://www.ebay.com
    TTFB: 513.901000ms, Total: 1019.546000ms
  Testing: https://www.wikipedia.org
    TTFB: 201.280000ms, Total: 298.359000ms
  Average TTFB: 322.59ms (3/3 successful)
  Average Load Time: 523.87ms (3/3 successful)

✓ Phase 2 completed


╔═══════════════════════════════════════════════════════════╗
║  Performance Comparison Results                           ║
╚═══════════════════════════════════════════════════════════╝

Ping Latency (Idle):
  Before: 63.347ms
  After:  36.638ms
  Improvement: 42.00% (better)

Latency Under Load:
  Before: 35.214ms
  After:  31.251ms
  Improvement: 11.00% (better)

Page Load - Time To First Byte:
  Before: 382.70ms
  After:  322.59ms
  Improvement: 15.00% (faster)

Page Load - Total Time:
  Before: 697.63ms
  After:  523.87ms
  Improvement: 24.00% (faster)

╔═══════════════════════════════════════════════════════════╗
║  Overall Assessment                                       ║
╚═══════════════════════════════════════════════════════════╝
✓ Network optimizer shows significant improvements (4/4 metrics)

╔═══════════════════════════════════════════════════════════╗
║  Benchmark completed!                                     ║
╚═══════════════════════════════════════════════════════════╝
mario@mario-Vivobook ~/G/l/Test > 

Schön, danke.