P2P Network Tester

WebRTC latency measures the actual peer-to-peer round-trip. Because traffic travels through both users' routers, ISPs, and any NAT hardware in between, the round-trip time you see here reflects real network conditions that server-based ping tools cannot replicate.¹ A 20 ms server ping can coexist with 80 ms peer-to-peer latency on the same connection. Running two browser instances on different connections and completing the WebRTC handshake gives you the number your video conferencing software experiences when it routes a call directly between participants.

The STUN probe on this page runs automatically before the connection begins.² Contacting public STUN servers from Google and Cloudflare, it discovers your public IP address and classifies your NAT type, which tells you whether your network supports a direct WebRTC data channel or will require relay infrastructure.³ Probe packets then travel directly between the two browser instances at 100 ms intervals, and each round-trip time lands on the live sparkline as it arrives.⁴

What round-trip time measures in WebRTC

Round-trip time in WebRTC is the elapsed time between one peer sending a probe packet and receiving the echo back from the other peer. Unlike a server ping, which measures the path to a datacenter, this measurement captures every router, switch, and NAT translation layer between the two browsers.⁵ Consequently, RTT values here are always higher than the same network's ping to Google.com. That gap represents the overhead of home router NAT, residential ISP routing, and any carrier-grade NAT sitting in between.Values below 30 ms indicate a direct LAN or very low-latency ISP path; values above 150 ms point to geographic distance, congested ISP links, or relay routing through TURN infrastructure.⁶

What causes elevated WebRTC RTT

Geographic distance is the largest single factor in peer-to-peer RTT. Light travels through fiber at roughly 200,000 km per second, so a trans-continental connection adds a physical minimum of 30 to 70 ms before any routing overhead.⁷ Building on this, ISP peering arrangements can add further delay; two connections on the same city block but served by different ISPs may route through distant peering points. Symmetric NAT forces all traffic through a TURN relay server, adding a server hop that typically contributes 20 to 60 ms depending on relay location.⁸ ISP congestion during peak evening hours raises RTT by 20 to 40 ms on many residential connections.⁹

Interpreting results and taking action

An average RTT below 50 ms with jitter under 5 ms indicates a healthy direct connection suitable for video calls and gaming. RTT between 50 and 150 ms with low jitter is usable for most real-time applications but may show buffering in video calls. RTT above 150 ms or jitter above 20 ms will produce audible artifacts in VoIP and visible stuttering in video.⁶

Using the ICE candidate type to prioritize fixes

Yet the most actionable signal is whether the ICE candidate type shows "srflx" (direct NAT traversal) or "relay" (TURN server path).³ Switching from relay to direct reduces RTT by the full relay server round-trip, typically 20 to 60 ms.⁸ Checking the candidate type before adjusting router settings avoids wasted effort on configurations that will not change the relay status. A relay path means the NAT topology prevents a direct connection, and no amount of local QoS tuning will bypass the need for the relay.

Isolating router-added latency from the ISP path

Total P2P RTT combines contributions from three distinct network segments: your local router's processing and queuing delay, the backbone routing between the two ISPs, and the remote peer's local routing. Treating the result as a single number hides which segment is responsible for elevated latency. The simplest isolation step is running both browser instances on the same local network using two different devices connected to the same router. The RTT produced by this same-LAN test reflects only router processing overhead and wireless delay, with no ISP path contribution.¹

A typical wired same-LAN RTT is 1 to 4 ms; Wi-Fi adds 2 to 10 ms depending on band and distance from the router.¹⁰ Subtracting this baseline from a cross-ISP measurement isolates the ISP backbone contribution. For example, if same-LAN RTT is 3 ms and cross-ISP RTT is 80 ms, the ISP path contributes approximately 77 ms. Repeating the cross-ISP test with the remote browser on a mobile hotspot from a different carrier reveals whether the backbone routing or carrier-grade infrastructure adds the gap.

When to run a same-LAN baseline before comparing connections

Running a same-LAN baseline whenever you evaluate a router change or QoS configuration establishes a clean reference point. If a configuration change increases same-LAN RTT from 3 ms to 8 ms, the router itself has become slower, not the ISP path. This distinction prevents misattributing router-side regressions to the ISP. For Wi-Fi evaluation, compare same-LAN RTT on 2.4 GHz versus 5 GHz versus wired to quantify wireless overhead independently before testing across locations.

Comparing wired and wireless WebRTC latency

Switching from wireless to wired Ethernet is the single most effective step for reducing P2P RTT and jitter on a home network. Wireless connections introduce variable queuing from 802.11 frame retransmissions: when a frame fails on first transmission and is retransmitted, the retransmission delay (typically 2 to 8 ms at 5 GHz) adds a jitter spike to that packet's arrival time.¹¹ On 2.4 GHz, neighboring network interference increases retry frequency, often producing 10 to 30 ms jitter on a lightly loaded connection.¹⁰

Connect one test device to Ethernet and leave the second on Wi-Fi, both on the same router, and run the P2P tester between them. The measured RTT reflects the wireless contribution to round-trip time, with no ISP path component. A 5 GHz device typically adds 2 to 8 ms over the wired baseline; a 2.4 GHz device on a congested band can add 10 to 30 ms.¹²

Determining whether excess RTT is wireless or ISP in origin

If your total cross-ISP RTT is unacceptably high, splitting same-LAN RTT from cross-ISP totals confirms whether the excess sits in the wireless segment or further upstream, comparing same-LAN RTT on Wi-Fi versus wired. Wireless excess shows in both same-LAN and cross-ISP measurements; ISP excess shows only in cross-ISP measurements. This two-step process prevents adjusting router wireless settings when the actual problem is an ISP backbone bottleneck that no router setting can address.

Running the same-LAN and cross-ISP measurements on a schedule keeps the reference points honest as your router firmware and ISP routing change. A baseline that drifts upward over several weeks usually points to ISP-side changes rather than your local hardware, especially when the same-LAN number stays flat. Treat the wireless-versus-ISP split as a repeatable routine, not a one-time check, so you can defend any router purchase or ISP complaint with current numbers.

Run this test when video calls feel laggy, when you want to compare wired and wireless connections, or when you need to verify that a router configuration change improved your direct peer-to-peer latency before committing to the change.

Packet loss breaks real-time communication in ways latency does not. A dropped packet in a voice call produces a click or silence; in a video stream it causes a freeze or artifact; in a game it causes desync or rubberband lag. Unlike latency, which increases slowly under congestion, packet loss can jump from 0% to 5% suddenly when a link reaches saturation, then drop back to 0% between bursts, making burst testing over a sustained period far more informative than a single-measurement tool.¹

This tester sends probe packets directly between two browser instances over a WebRTC data channel, with probes every 100 ms. Any probe that does not return an echo within 2 seconds counts as a lost packet. Because the traffic follows the actual peer-to-peer path (through your router, ISP, and the remote peer's ISP), the loss reading reflects the real conditions your video call or game session experiences, not the cleaner path to a nearby server.

What causes peer-to-peer packet loss

ISP link saturation is the most common cause of P2P packet loss at home. When your upload bandwidth is fully consumed by another application (a file upload, a video stream, or a background system update), the router drops new packets because the outbound queue is full.² This type of loss affects all connections using the same ISP link simultaneously, not just the WebRTC stream.

How wireless interference produces a different loss signature

Wireless interference produces a different pattern from ISP saturation: short bursts of 2 to 5% loss while the radio retransmits corrupted frames, followed by clean recovery once the interference subsides. Building on this distinction, comparing loss on Wi-Fi versus wired separates radio-layer loss from ISP-layer loss immediately. Run the test on both connections back to back; if loss disappears on Ethernet, the wireless link is the source rather than your ISP.

Simulated loss versus real loss in this tool

This tool displays two loss values: simulated loss from the slider control and real loss from timed-out probes. The simulated loss slider drops outbound packets at the send layer before they enter the network, which is useful for testing how your application handles degradation at a known rate. Real loss counts probes that were transmitted but never echoed back within 2 seconds. Consequently, you can compare the two: if simulated loss is 0% and real loss is 2%, your ISP path is dropping 2% of packets independently of the simulation. Yet if simulated loss matches the slider value exactly and real loss is 0%, your ISP path is clean.

Acceptable packet loss thresholds for real-time applications

Voice calls become noticeably degraded above 1% packet loss. At 3% loss, VoIP codecs skip syllables and callers ask for repetition.³ Video calls tolerate slightly more loss; most codecs recover with a single-frame artifact up to 2 to 3%, but sustained 5% loss breaks adaptive bitrate systems and forces resolution drops.³ Gaming is the most sensitive: 1% loss on a 20 Hz game server tick causes one missed update per 5 seconds, which produces visible desync.⁴ Conversely, file transfers and web browsing tolerate 5 to 10% loss transparently through TCP retransmission, which is why loss often goes unnoticed until real-time applications expose it.⁵

Bufferbloat and queue saturation as a source of burst loss

Bufferbloat describes a condition where a router's outbound queue grows large enough to absorb a substantial fraction of available bandwidth before overflowing.¹ During the overflow, the router drops all arriving packets until the queue drains. This produces a burst loss pattern: zero loss during normal traffic, a sudden 3 to 10% burst when a file upload or video stream fills the queue completely, then a return to zero. The burst coincides with a large RTT spike visible in the sparkline, because packets that eventually drop waited in the queue while RTT climbed.

Pure path loss (a physical link dropping packets due to RF errors or hardware failure) distributes drops randomly and does not correlate with RTT increases. Bufferbloat loss, by contrast, always coincides with elevated RTT because queued packets experience the same delay before dropping. Watching the sparkline for simultaneous RTT elevation and loss accumulation identifies bufferbloat as the source. A router running an Active Queue Management algorithm such as CAKE or fq_codel eliminates bufferbloat by limiting queue depth proactively rather than waiting for the queue to overflow.²

Using RTT and loss together to diagnose bufferbloat

Start a large file upload in a separate browser tab while the loss test runs, then watch RTT and loss spike together: if RTT climbs from 20 ms to 200 ms and loss simultaneously rises above 1%, the router queue is full. Stopping the upload should return both RTT and loss to baseline within a few seconds. If loss persists after RTT recovers, the source is the ISP path rather than the local queue. The correlation between RTT elevation and loss accumulation is the definitive signature of bufferbloat: when both metrics spike together and recover together, the local router queue is the bottleneck rather than the ISP backbone or the remote peer's connection.

Testing application resilience with the simulation slider

For developers verifying how a VoIP client or video conferencing tool handles network degradation, the simulation slider introduces a controlled loss source without requiring a degraded ISP path. Setting the slider to 3% while your application runs on the same connection reveals whether the codec's packet concealment activates at the correct threshold and whether the adaptive bitrate logic responds within the expected time window. The simulation operates at the send layer: probe packets are dropped before entering the network stack, producing a precise application-layer loss condition independent of the actual ISP path quality.

Pairing the loss slider with the artificial latency slider replicates typical evening-congestion conditions: 80 ms of simulated latency alongside 3% loss recreates a congested residential ISP path during peak hours. Running your application through this combined degradation for five minutes tests sustained behavior rather than a transient response. CapyToolkit does not inject any additional network conditioning beyond what the sliders you configure specify, so you remain in full control of the test parameters throughout the session.

Interpreting simulated versus real loss counters

The tool displays simulated loss and real loss as separate counters. When the slider is at 3% and real loss shows 0.2%, your ISP path contributes 0.2% independently of the simulation. If the ISP path itself produces 3% loss alongside the simulated 3%, your application receives 6% total. Tracking both counters separately gives an accurate picture of what the application actually experiences under combined conditions. This separation is particularly valuable when you are evaluating a video conferencing platform's performance: the slider tests how the codec handles a known degradation rate while the real counter reveals whether your ISP path adds additional loss on top of that simulation.

This split view also helps you judge whether a router upgrade will actually help, because only the real counter reflects the path your traffic truly traverses. If the simulated slider matches your target but real loss stays high, the bottleneck is the link itself rather than the application's handling of degradation. Keeping both numbers visible during a sustained test prevents you from mistaking codec concealment for a clean connection when the underlying path is still dropping packets.

Run this test when voice calls produce clicks or dropouts, when gaming sessions show rubberbanding that a ping test does not explain, or when you suspect your ISP path to a specific geographic region drops packets under load.

Jitter undermines smooth real-time communication more than consistent latency. A connection with 80 ms average RTT and 2 ms jitter feels stable in a video call; the same 80 ms average with 25 ms jitter produces audible skips and video freezes as the adaptive buffer cannot absorb the irregular arrival pattern. Jitter is the standard deviation of packet arrival times; high jitter means some packets arrive much earlier and some much later than the average, forcing the receiver to buffer more aggressively or drop frames.¹

This tester measures jitter using an RFC 3550 exponential weighted moving average applied to the probe packet round-trip times. Probes travel directly between two browser instances every 100 ms, and the jitter statistic updates continuously as new samples arrive. Because probes follow the actual peer-to-peer path through both ISPs and both routers, the jitter value reflects real conditions your audio and video applications experience.

What causes network jitter

Queue buildup at an intermediate router is the most common source of jitter on residential connections. When a router's outbound queue fluctuates between empty and partially full as traffic bursts arrive and depart, packets experience variable queuing delay that produces jitter without increasing average RTT substantially. The effect is most noticeable during large file uploads competing with real-time traffic.

How Wi-Fi retransmissions add radio-layer jitter

Wi-Fi introduces a second source: radio retransmissions add an additional backoff delay when a frame fails on the first attempt, producing a spike on specific packets rather than a uniform delay increase. Building on these two sources, comparing jitter on wired versus wireless connections on the same ISP separates radio-layer jitter from network-layer jitter immediately. The distinction matters because each source requires a different fix: network-layer jitter responds to QoS configuration on the router, while radio-layer jitter requires a band change or channel switch.

Acceptable jitter thresholds for different applications

VoIP applications tolerate up to 20 ms jitter when a jitter buffer is active. Above 30 ms, even well-tuned jitter buffers introduce audible gaps because the buffer must grow large enough to absorb the timing variation, adding a corresponding fixed latency.² Video conferencing applications adapt more readily (adaptive bitrate encoding absorbs some jitter by varying resolution), but above 40 ms of P2P jitter, visual artifacts become frequent.³ Consequently, a jitter reading below 10 ms at the P2P layer indicates a stable path. Readings between 10 and 30 ms suggest moderate congestion. Readings above 30 ms warrant investigation of Wi-Fi channels, router QoS settings, or ISP-level congestion.

Reducing jitter at the router level

Quality of Service (QoS) settings on the router prioritize real-time UDP traffic over bulk TCP transfers, preventing file downloads from filling the outbound queue and causing jitter for concurrent voice or video traffic. Most modern routers expose QoS controls under their WAN or traffic management settings. Enabling real-time media priority dramatically reduces jitter caused by competing background transfers. Furthermore, switching from a congested 2.4 GHz band to 5 GHz reduces wireless-layer jitter by avoiding interference from neighboring networks. For persistent jitter above 20 ms on a wired connection, the source is likely the ISP path itself. CapyToolkit's jitter tester built on live WebRTC probes lets you validate whether a QoS change actually reduced the jitter your real-time applications experience, rather than relying on the router's internal traffic counters alone.

802.11 retransmission mechanics and radio-layer jitter

Wi-Fi jitter originates at the 802.11 MAC layer before packets reach the IP stack. The 802.11 standard uses CSMA/CA (Carrier Sense Multiple Access with Collision Avoidance): each device waits for the channel to be idle, then waits an additional random backoff period before transmitting.⁴ When two devices transmit near-simultaneously, both defer for a longer backoff period and the deferred frame arrives late at the IP layer as a jitter spike. On a lightly loaded 5 GHz network with few neighboring networks, this backoff process adds 1 to 5 ms per collision event. On a congested 2.4 GHz channel shared with neighboring Wi-Fi networks and Bluetooth devices, collision frequency increases substantially, raising jitter to 10 to 30 ms per affected packet.

802.11 frame retransmission compounds this effect. When a transmitted frame is not acknowledged by the receiver (due to signal fading or interference), the 802.11 MAC retransmits up to seven times before declaring the frame lost.⁵ Each retransmission attempt takes 1 to 3 ms at 5 GHz, adding a jitter spike proportional to the number of retransmissions needed.

Confirming radio-layer versus ISP-layer jitter

Run the jitter test simultaneously on a wired connection and on the Wi-Fi connection for the same router. The wired result shows ISP-layer jitter; the Wi-Fi result shows ISP-layer plus radio-layer jitter combined. Subtracting the wired result from the Wi-Fi result isolates the radio contribution. If radio-layer jitter exceeds 10 ms on a 5 GHz connection, check the router admin panel for neighboring networks sharing the same channel and switch to a less congested channel.

How jitter buffers in video conferencing platforms respond to P2P jitter

Jitter buffers in video conferencing applications hold incoming audio packets temporarily before playing them, smoothing out arrival variation at the cost of a fixed delay equal to the buffer depth.⁶ Zoom, Microsoft Teams, and Google Meet all implement adaptive jitter buffers that grow when measured incoming jitter increases and shrink when the path stabilizes. A P2P jitter of 15 ms causes the adaptive buffer to maintain a depth of approximately 20 to 25 ms, adding a corresponding fixed delay to every call. Sustained jitter above 40 ms forces the buffer beyond its practical ceiling, causing the application to drop packets that arrive outside the buffer window.³

Understanding the relationship between measured P2P jitter and call quality provides meaningful improvement targets. Reducing jitter from 30 ms to 8 ms allows the application's jitter buffer to halve its depth, reducing the buffer-induced fixed delay by approximately 15 ms on top of the jitter improvement itself. This reduction is perceptible to callers because the total end-to-end delay drops by a corresponding amount, making the conversation feel more natural and responsive for everyone on the call.

Verifying jitter improvement after a QoS or band change

After enabling QoS or switching from 2.4 GHz to 5 GHz, run the jitter tester for at least five minutes while performing normal activity on the same network. A QoS change that reduces jitter from 25 ms to 5 ms during a competing file download confirms traffic prioritization is working correctly. If jitter remains above 15 ms even on a lightly loaded network, the ISP path is the source, and router-side QoS provides no benefit for upstream congestion.

A clean before-and-after comparison matters most because jitter can vary hour to hour on a shared neighborhood link regardless of your router settings. If the post-change reading looks good at midnight but climbs again at eight in the evening, the improvement is real but the ISP congestion remains the dominant factor. Re-running the verification during the same busy window that prompted the change gives a fair measure of whether the QoS or band adjustment actually moved the number you care about.

Run this test when voice calls have audio skips that a latency measurement does not explain, when video calls stutter despite adequate bandwidth, or when you want to confirm that a QoS configuration change reduced real-time traffic jitter.

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.

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.