SRT Latency Tuning: Optimize for Your Network

How to configure SRT latency for optimal performance. Balance between low delay and packet loss recovery.

Understanding SRT Latency

SRT’s latency parameter is the most important setting you’ll configure. It controls the receive buffer size, the window of time SRT has to detect and recover lost packets before they’re needed for playback.

Set it too low: you get artifacts when packets can’t be recovered in time. Set it too high: you add unnecessary delay to your stream.

The goal is to find the sweet spot for your specific network conditions.

The Formula

A good starting point:

SRT Latency ≥ 4 × RTT

Where RTT is the round-trip time between caller and listener. This gives SRT enough time to:

  1. Detect a missing packet (1 RTT)
  2. Request retransmission (instantaneous)
  3. Receive the retransmitted packet (1 RTT)
  4. Have margin for jitter and multiple retransmissions (2 RTT)
ScenarioTypical RTTRecommended LatencyNotes
Same LAN<1ms20-60msMinimal buffer needed
Same building (Wi-Fi)2-5ms60-120msWi-Fi jitter adds variance
Same city (fiber)3-10ms120-200msStable, predictable
Same country10-40ms200-500msStandard internet routing
Cross-continent50-150ms500-1500msSignificant distance
Satellite/VSAT250-600ms1500-4000msHigh RTT, some jitter
Cellular (4G/5G)20-100ms500-2000msVariable conditions
SRTLA bondingvaries1000-3000msMultiple path variance

Measuring Your RTT

Before configuring latency, measure your actual RTT:

Method 1: Ping

ping your-server.com

Take the average RTT and multiply by 4.

Method 2: SRT Statistics

Once connected, SRT reports RTT in real-time. Vajra Cast displays this in the stream dashboard. Start with a generous latency (2000ms), then reduce based on observed RTT.

Method 3: Network Path Analysis

For production deployments, use mtr or traceroute to understand the full network path:

mtr --report your-server.com

Look at the worst-case RTT along the path, not just the average.

Fine-Tuning

Start High, Go Low

  1. Begin with latency = 2000ms (safe for most scenarios)
  2. Monitor packet loss and recovery stats
  3. Reduce by 25% increments
  4. Stop when you see unrecovered packets appearing

Watch for Jitter

Jitter (RTT variance) matters as much as average RTT. A path with 20ms average RTT but 50ms jitter spikes needs more buffer than a path with 40ms stable RTT.

Rule: Add your observed jitter to the 4×RTT formula:

Latency ≥ 4 × RTT + 2 × Jitter

Overhead Bandwidth

The oheadbw parameter (overhead bandwidth percentage) controls how much extra bandwidth SRT can use for retransmissions:

srt://server:9000?oheadbw=25
  • Default: 25%
  • Lossy networks: increase to 50-100%
  • Clean networks: decrease to 10-15%

More overhead bandwidth = better recovery but higher bandwidth usage.

Maximum Bandwidth

Set maxbw to cap total bandwidth (content + retransmissions):

srt://server:9000?maxbw=0
  • 0 = automatic (recommended for most cases)
  • Set explicitly if you have strict bandwidth limits

Common Patterns

Pattern 1: Studio to Cloud (Stable Network)

Latency: 200ms
Overhead: 15%
MaxBW: auto

Low RTT, clean network. Minimal buffer needed.

Pattern 2: Remote Production (Public Internet)

Latency: 800ms
Overhead: 25%
MaxBW: auto

Moderate RTT, occasional packet loss. Standard configuration.

Pattern 3: Mobile/Cellular (SRTLA)

Latency: 2000ms
Overhead: 50%
MaxBW: auto

High jitter, variable RTT. Generous buffer for path switching.

Latency: 4000ms
Overhead: 30%
MaxBW: explicit (match your satellite bandwidth)

Very high RTT, but typically stable once established.

Monitoring in Production

Key metrics to watch continuously:

  • Retransmitted packets: non-zero is normal; sustained high values suggest latency is too low
  • Dropped packets: any drops mean your latency is definitely too low
  • Buffer level: shows how much of your latency buffer is being used
  • RTT trend: increasing RTT may require a latency adjustment

Vajra Cast provides all these metrics in real-time, plus historical graphs for trend analysis.

Next Steps

← Back to main guide