What it controls

Duration controls how long the test runs. The longer it runs, the more data it collects, which makes packet loss, latency, and jitter results more accurate.

Why it matters

Short bursts of packet loss are easy to miss in a 10-second test. A 30 or 60-second test is far more likely to catch intermittent drops that happen every few seconds — the kind that cause brief audio glitches in video calls or momentary lag in games.

Recommendations

• Quick (10s) — Good for a fast sanity check when you suspect an obvious problem.
• Standard (30s) — The best balance between speed and accuracy for most users.
• Extended (60s) — Use this when your issue is intermittent or hard to reproduce. The longer window catches problems that appear only occasionally.

What it controls

This sets the size of each UDP probe packet sent during the test, measured in bytes. The default is 200 bytes — roughly the size of a VoIP audio frame.

Why it matters

Some network problems only appear with larger packets. For example, a misconfigured MTU (Maximum Transmission Unit) on a router may silently drop packets above a certain size, which would go undetected with small packets. Conversely, a heavily congested link may drop large packets while letting small ones through.

Recommendations

• 200 B (default) — Matches typical VoIP and real-time app traffic. Best for general testing.
• 500–1000 B — Use this to simulate web browsing or moderate file transfers.
• 1400 B — Close to the maximum for most links (Ethernet MTU is 1500 bytes minus headers). Useful for detecting MTU issues or fragmentation problems.
• Large sizes (1400+ B) may be dropped by some paths — a high loss result at large packet sizes but not at small ones is a strong signal of an MTU issue.

What it controls

This sets how many UDP packets are sent per second. Combined with packet size, it determines the total test bandwidth: Bandwidth ≈ Packets/sec × Packet size.

Why it matters

Sending packets at a higher rate puts more load on your connection and is more likely to expose problems under traffic. At 100 packets/sec with 200-byte packets, the test uses about 160 Kbps — light enough not to interfere with normal usage but enough to measure real-world performance.

Approximate bandwidth used

• 50 /s × 200 B ≈ 80 Kbps (Quick preset)
• 100 /s × 200 B ≈ 160 Kbps (Standard preset)
• 200 /s × 200 B ≈ 320 Kbps (Extended preset)

Recommendations

• Lower rates (50/s) — Good for slow connections or mobile data where you want minimal impact.
• Standard rates (100/s) — Best for home broadband. Realistic VoIP-like load.
• Higher rates (200–500/s) — Use when testing under load, or if you want to stress-test your link to reproduce issues that only appear when the connection is busy.

What it controls

The delay threshold sets your personal acceptable latency limit in milliseconds. The test uses this value to classify individual packets as on-time, delayed, or excessively delayed — similar to how a video conferencing system decides when a packet is "too late to use."

How ratings are calculated

• Good — Packet arrived within the threshold (e.g., within 50ms).
• Fair — Packet arrived within 3× the threshold (e.g., 50–150ms).
• Poor — Packet arrived more than 3× above the threshold (e.g., >150ms) or was lost entirely.

Why it matters

Different applications have different latency budgets. A video call can tolerate up to ~150ms one-way delay before users notice. Online gaming needs under 50ms. A file download doesn't care about latency at all. By setting this threshold to match your use case, the quality ratings become meaningful for you specifically rather than using a generic cutoff.

Recommendations

• 20–30 ms — Competitive online gaming or real-time interactive applications.
• 50 ms (default) — General use: video calls, VoIP, casual gaming. Good balance for most users.
• 100–150 ms — Standard voice calls or streaming where minor delays are acceptable.
• Increase this if you are on a satellite or high-latency connection and want to test for loss specifically, independent of latency.