Network Stability Test: Measure Jitter and Loss Over Time

Network Stability Test: Measure Jitter and Loss Over Time

Network stability shows up over time, not in a single sample. A connection that reports 5 ms average RTT and 0% loss in a 10-second window may experience 30 ms jitter spikes and 2% loss bursts every 90 seconds as background processes contend for bandwidth. Single-shot speed tests and brief ping runs miss these patterns entirely. Sustained P2P testing over 2 to 5 minutes captures the variance that brief tests obscure, revealing whether a connection is genuinely stable or only appears stable during idle windows.

This tool runs WebRTC probe packets at 100 ms intervals between two browser instances continuously for as long as the session remains open. The sparkline visualizes individual RTT values over time, and the running jitter and loss statistics accumulate across the full session. Patterns visible in the sparkline (periodic spikes, sustained elevation, or gradual drift) each point to different root causes that a single average number cannot reveal.

Identifying instability patterns in the sparkline

Periodic RTT spikes at regular intervals (every 30, 60, or 120 seconds) indicate a background process waking up and consuming bandwidth or CPU. Common causes include backup software, system update checks, antivirus scans, and router firmware processes. Sustained RTT elevation that appears gradually then subsides points to ISP congestion accumulating on a shared link during peak hours. Random intermittent spikes with no pattern suggest wireless interference or packet queue management in the router. Consequently, running the test for at least five minutes and noting the time when spikes occur gives you enough data to correlate with system activity logs. CapyToolkit's sparkline updates in real time as each probe returns, so you can identify the exact moment a spike occurs and cross-reference it with other activity on your network.

How to distinguish the three common sparkline shapes

Periodic spikes at fixed intervals point to a scheduled process on your network, while sustained elevation that builds gradually points to ISP congestion on a shared link. Random intermittent spikes with no timing pattern point to wireless interference or router queue management. Recognizing which shape you are seeing narrows the cause to a specific category before any configuration changes are attempted.

Distinguishing transient from sustained instability

A single packet spike to 200 ms in an otherwise clean 15 ms stream is transient (a momentary queue buildup that resolved immediately). Sustained instability is a different condition: RTT that stays elevated above 50 ms for 10 or more consecutive seconds, or loss that accumulates above 1% over the full session¹. Building on this distinction, the test displays both current values and running totals; comparing the current value against the session total reveals whether an observed spike is a brief outlier or part of a sustained degradation. Running the test across different times of day confirms whether the instability is time-correlated, which is the first step toward determining whether the cause is local (a scheduled process on your network) or external (ISP congestion that affects many subscribers simultaneously).

Using simulation to stress-test connection stability

The artificial latency slider adds a fixed delay to all outbound probes, simulating a higher-latency path. Combining this with the loss slider at 1 to 2% replicates typical peak-hour ISP congestion conditions. Running this simulated stress load for five minutes while monitoring whether the RTT remains stable rather than compounding upward confirms whether the connection can sustain a degraded baseline without further deterioration. Furthermore, starting a large file transfer in the background while the stability test runs reveals how the connection behaves under combined load: a well-configured QoS router maintains stable probe RTT despite the competing download. The simulation operates at the send layer, so the degradation you introduce with the sliders is independent of the actual ISP path quality, allowing you to test worst-case scenarios even when your current internet connection is clean.

Active Queue Management algorithms and long-running stability

The queue management algorithm a router uses has a direct effect on long-running stability results. Traditional FIFO (First In, First Out) queuing with tail-drop discards packets when the buffer overflows and allows the queue to grow large during traffic bursts, producing RTT spikes that persist until the queue drains. CAKE (Common Applications Kept Enhanced)² and fq_codel (Fair Queuing Controlled Delay)³ are Active Queue Management algorithms that limit queue depth proactively, keeping RTT stable even under sustained load. Routers running OpenWrt, ASUSWRT-Merlin, or DD-WRT can enable CAKE as the queuing discipline on the WAN interface, replacing the default FIFO queue.

A stability test run for five minutes with CAKE enabled shows a flat sparkline under load: RTT stays near baseline even when a large file download is running simultaneously on the same connection. The same test on a FIFO router shows RTT rising from 15 ms to 200 ms as the download fills the queue, producing instability that affects all real-time traffic. Checking whether your router firmware supports CAKE or fq_codel and enabling it under the WAN interface QoS settings is the most impactful single configuration change for long-running stability metrics.

Enabling CAKE on OpenWrt or Merlin firmware

On OpenWrt, install the sqm-scripts package and configure it via Network > SQM QoS. Set the download and upload rates to 90% of your ISP connection speed, select "cake" as the queue discipline, and "piece_of_cake" as the script⁴. On ASUSWRT-Merlin, navigate to Adaptive QoS, enable it, and set the upload and download bandwidth to match your ISP plan. After enabling AQM, re-run the stability test under load and verify that RTT no longer spikes above 1.5x the idle baseline.

Correlating stability readings with router and system logs

Stable RTT that spikes at exactly regular intervals (every 30, 60, or 300 seconds) reflects a scheduled process rather than random network congestion. On Windows, Task Scheduler runs maintenance tasks on fixed intervals; scheduled tasks generating network traffic (Windows Update checks, telemetry uploads, antivirus definition downloads) create predictable RTT spikes. On macOS, the mds_stores (Spotlight indexing) and cloudd (iCloud sync) processes generate periodic upload bursts. Matching the spike interval in the stability test sparkline to a scheduled task in the system's task scheduler or process log identifies the culprit without requiring packet capture.

Router firmware logs record WAN link events, DHCP renewals, and QoS queue overflows with timestamps. Downloading the router log after a stability test session and comparing timestamps of RTT anomalies in the sparkline against log entries at the same timestamps reveals whether the instability originated at the WAN interface or inside the LAN. Most consumer routers expose system logs under Administration > System Log.

Combining device traffic monitoring with the stability test

Pairing this stability test with ASUS, TP-Link, or Netgear's per-device traffic page shows in real time which LAN device generates bandwidth at each spike timestamp. Identifying which device causes a burst at each spike narrows the cause to a specific device and application before any configuration changes are attempted. For persistent instability where device-level traffic shows no burst, the source is the ISP path itself, confirmed by running the test from a different network connection and observing whether the pattern disappears.

Correlating the two views removes the guesswork of blaming the ISP when a household device is actually the cause of the spike. A laptop backup or phone sync that lines up exactly with each anomaly in the sparkline is far easier to fix than a vague complaint to your provider about intermittent lag. Repeating this combined check after moving the offending device to a different band or schedule confirms the fix and keeps your stability baseline clean without involving outside support.

When to use this

Run this test when intermittent connection problems are suspected but brief tests show normal results, when validating a network upgrade over a sustained window, or when monitoring whether ISP congestion occurs at a predictable time each day.

Examples