Why JitterTrap
The Timing Problem
Standard network tools measure averages. Throughput over the last second. Latency over the last minute. Packet loss as a percentage.
Real-time systems don't experience averages. They experience individual packets arriving at specific moments. A stream can average 100 Mbps and still stutter if packets arrive in bursts. A 20 ms average latency hides the 200 ms spike that caused a timeout.
The gap between averages and reality is where real-time systems fail.
→ JitterTrap shows inter-packet timing and per-flow breakdown in real-time, not averages.
Real-Time Feedback
When you're debugging a timing problem, you need to see what's happening now—not what happened in a log file you'll analyze later.
Change something in your system and see the effect immediately. Inject an impairment and watch how the traffic responds. This tight feedback loop makes debugging faster—you're observing directly, not guessing and checking logs.
→ JitterTrap's live charts update continuously. Inject impairments and watch the response.
The Data Volume Problem
A 1 Gbps link generates roughly 125 MB of packet data per second. You can't capture everything forever—disk fills up, analysis becomes impractical.
Wireshark solves this by capturing selectively: start capture, reproduce problem, stop capture. But what if the problem happens unpredictably? Once an hour? Once a day?
→ JitterTrap uses a sliding window buffer. It captures continuously, discarding old data as new data arrives. When a threshold is violated, it saves the buffer—giving you a pcap of the event and the seconds leading up to it. Set it and come back to evidence.
Measurement Resolution
Many monitoring tools aggregate data over seconds or minutes. Fine for capacity planning; useless for real-time debugging.
Real-time applications care about milliseconds:
- Audio: packet intervals of 1–20 ms
- Video: frame intervals of 16–40 ms
- Control systems: cycle times of 1–100 ms
JitterTrap can measure at intervals down to 10 ms. At that resolution, data scrolls quickly—the chart holds a fixed number of points, so the time window is short. You can see throughput and inter-packet gap for each 10 ms slice, but only if you pause the chart at the right moment.
→ Use a trap to pause automatically when a threshold is exceeded. The chart freezes, showing the event. Export the pcap for detailed analysis in Wireshark.
Structured Testing
Ad-hoc debugging finds problems. Structured testing prevents them.
→ JitterTrap supports reproducible test conditions with controlled impairments and programmed sequences:
| Phase | How JitterTrap Helps |
|---|---|
| Development | Verify timing behavior before committing code |
| Integration | Check that components work together under stress |
| Regression | Confirm changes don't degrade performance |
| Acceptance | Demonstrate the system meets requirements |
Impairment + Observation
Most tools do one or the other. Wireshark observes but doesn't inject. tc/netem injects but doesn't visualize.
→ JitterTrap does both simultaneously. Inject delay and watch the TCP RTT chart respond. Add packet loss and see retransmission markers appear.
This combination lets you:
- Find the threshold where your system degrades
- Verify that fixes actually work
- Understand why something fails, not just that it fails
Get Started
- Compare — See how JitterTrap relates to other tools
- Getting Started — Build and run JitterTrap