Also known as: throttle, throttle block
A throttle is a pipeline block that limits how fast samples move through a flowgraph, sleeping as needed so the average throughput matches a specified sample rate.1 It exists to solve one problem: a flowgraph whose source is a file or a generator has no clock of its own and will otherwise run as fast as the CPU can go, so a throttle re-imposes the wall-clock pace that real hardware would have provided.
How it works
A throttle passes samples through unchanged; its only effect is timing. It records a start time and a running count of samples emitted, and before releasing the next batch it computes how long that many samples should have taken at the target rate. If it is ahead of that schedule, it sleeps the difference; if it is behind, it passes data straight through. Over time the emitted count tracks wall-clock time multiplied by the rate, so the stream averages the requested samples per second.
Because a throttle only slows things, it applies back-pressure upstream: while it is sleeping it is not reading its input, so the file source blocks and the whole chain idles at the set rate instead of busy-spinning a core to 100%. That single property — turning a CPU-bound loop into a paced, low-load stream — is the practical reason it exists.
In practice
- Exactly one per flowgraph. Two throttles fighting over the same stream produce erratic timing; the convention is a single throttle just after the source.
- Never alongside real hardware. A live SDR source already sets the clock. Adding a throttle then makes two clocks compete, causing the hardware to overflow — so a throttle is strictly a hardware-less tool.
- Pacing, not precision. Because it works by sleeping in chunks, a throttle’s instantaneous rate is lumpy; it guarantees the long-run average, not sample-accurate timing. For anything needing true determinism you drop the throttle and let the consumer set the pace directly.
Relevance to SDR
The throttle is the canonical bridge between offline data and a pipeline built to run in real time. When you develop against a recorded capture or a simulation-driven signal generator, the throttle lets you watch a spectrum or constellation update at a lifelike rate, and keeps a demo or GUI from saturating the CPU. Every block-based SDR framework ships one for this reason.
GopherTrunk takes a different but related approach to the same need. For deterministic testing and its .cfile replay path, GT does not pace to wall-clock at all — it lets the decoder consume the file as fast as it can, which makes offline runs both reproducible and quick, and its decode chain is rate-invariant so the result matches a live capture. Where GT does want lifelike pacing (for example driving a live-style visual from a file), the same throttle idea applies: meter the file source to the capture’s sample rate. The distinction to keep honest is that throttling buys realistic timing, whereas GT’s test path deliberately gives that up in exchange for speed and determinism.
Sources
-
Throttle block — GNU Radio Wiki, on pacing a flowgraph to a sample rate when no hardware clock is present. ↩