RTT and Bitrate — What the Bot Tells You in Chat

When you type !b in chat, you get numbers like "RTT 45 ms, Bitrate 4850, SRT 0.2% loss". What does that mean? We explain every metric.

RTT and Bitrate — What the Bot Tells You in Chat

When you type !b into your Twitch chat, the FizzyPeak bot replies with a wall of numbers: "RTT: 45 ms, Bitrate: 4850 kbps, Loss: 0.2%, Buffer: 2.3 s". So you don't just see them but understand and fix them, we break down each metric individually here.

RTT (Round Trip Time)

What it is: The time it takes a data packet to travel from your encoder to the FizzyPeak ingest and back.

Unit: milliseconds (ms)

Good:

• < 50 ms — excellent, Wi-Fi or strong 5G
• 50–150 ms — normal for mobile IRL streaming
• 150–300 ms — high, but streamable
• > 300 ms — critical, quality suffers

What affects RTT:

• Distance to the ingest (the closer, the better)
• Mobile network quality
• Number of hops in the route

Fix for high RTT:

• Choose a closer ingest (see "Ingest while traveling")
• Activate a more stable SIM card
• Avoid indoor-outdoor transitions

Bitrate

What it is: How many kilobits per second your stream is currently sending.

Unit: kbps (kilobits per second)

Typical targets:

• 720p @ 30 fps → 2500–3500 kbps
• 1080p @ 30 fps → 4000–5500 kbps
• 1080p @ 60 fps → 6000–8000 kbps

Important: The bitrate in the !b output shows your current output, not your target. If you actually want 5000 kbps and only 2800 arrives, adaptive bitrate is throttling you.

Fix for too-low bitrate:

• Check signal strength — use !s to query location stats
• Check multiple SIMs to see whether they're all bonding
• Lower the bitrate target in the encoder if the network is too weak

Packet Loss

What it is: The share of packets lost between the encoder and the ingest.

Unit: %

Good:

• 0% — perfect
• < 0.5% — normal, no visible effects
• 0.5–2% — noticeable, but compensable via SRT
• > 2% — visible artifacts, audio glitches

Difference SRT vs. SRTLA:

• SRT has limited error correction, needs a larger latency buffer
• SRTLA compensates for loss via bonding automatically

Fix for high loss:

• Change location (mobile tower issue)
• Increase latency in SRT (latency=1500000)
• If possible: switch to SRTLA

Buffer (Latency Buffer)

What it is: How many seconds of data your ingest buffers to compensate for packet loss.

Unit: seconds

Typical values:

• 1–2 s — aggressive, minimal latency, prone to loss
• 2–4 s — standard for FizzyPeak
• 4–8 s — safe for poor networks

Fix: Adjust the latency setting in the encoder. In OBS: SRT URL with latency=3000000 (3 sec).

CPU / Encoder Load

What it is: How busy your encoder device is (phone, Belabox, PC).

Good: < 70% over an extended period

Problem at > 85%:

• Dropped frames
• Bitrate can't be maintained
• Thermal throttling looms

Fix:

• Lower the resolution (1080p → 720p)
• Set the encoder preset from "slow" to "fast" (costs quality)
• Cool the device

All in one sentence

With !b you have 90% of the diagnostics you'll ever need. Memory rule:

RTT low, bitrate equal to target, loss under 0.5%, buffer 2–4 s → your stream is fine.

If one of the values deviates strongly, work through the table above and fix the root cause. Spamming !f or !restart without diagnosis usually makes it worse.

Dashboard alternative

If you don't want to rely on chat, open the FizzyPeak dashboard on a second device during your stream. Under Stream Health you can see all values live as a graph — in real time, without !b commands.

Noch Fragen? Öffne das Dashboard oder schreib im Discord #support.