From b356a165290b8910c318e285bd4be5fc38cfb76a Mon Sep 17 00:00:00 2001 From: team3 Date: Mon, 31 Aug 2026 20:47:59 +0200 Subject: [PATCH] README: BBR auf dem sendenden Rechner MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Ohne die Einstellung ruckelt der Stream, und die Ursache ist von außen nicht zu erkennen: Es sieht nach zu wenig Bandbreite aus, ist aber der Stau-Algorithmus, der auf den vollen Modempuffer hereinfällt. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_013XVnRop5c3or3B8xE2hpgZ --- README.md | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) diff --git a/README.md b/README.md index b1c9707..9225f74 100644 --- a/README.md +++ b/README.md @@ -146,6 +146,30 @@ Bitrate und Auflösung stehen in `~/.config/obs-studio/basic/profiles/filmabend/basic.ini` und werden nur beim ersten Mal geschrieben. Das Sendeziel aktualisiert das Skript jedes Mal. +### Der sendende Rechner braucht BBR + +Einmalige Einstellung, ohne die der Stream ruckelt: + +```bash +printf 'tcp_bbr\n' | sudo tee /etc/modules-load.d/bbr.conf +printf 'net.core.default_qdisc=fq\nnet.ipv4.tcp_congestion_control=bbr\n' \ + | sudo tee /etc/sysctl.d/99-bbr.conf +sudo sysctl --system +``` + +Warum: Kabelanschlüsse puffern den Upload großzügig. Unter Last stieg die +Latenz hier von 26 auf 181 ms, ohne einen einzigen Paketverlust. Der +Standard-Algorithmus `cubic` liest den Latenzanstieg als Stau und drosselt. +Eine einzelne Verbindung kam so auf 4,5 statt 25 Mbit/s — und RTMP nutzt +genau eine. OBS warf daraufhin 45 % der Bilder weg. + +BBR misst stattdessen den tatsächlichen Durchsatz und lässt sich davon nicht +täuschen. Danach: 0 % verworfen. `fq` gehört dazu, BBR braucht diese +Warteschlange für seine Sendetaktung. + +Prüfen mit `sysctl -n net.ipv4.tcp_congestion_control` — es muss `bbr` +antworten. + Von Hand geht es auch: | Feld | Wert |