Fast symptom-to-evidence table
Use the table to choose the next artifact, not to skip diagnosis. Scroll horizontally on smaller screens.
| Observed clue | Boundary it supports | Evidence to inspect | Do not overclaim |
|---|---|---|---|
| Large downloads slow, latency normal | Throughput/capacity/application limit | transfer rate, utilization, server control | Bandwidth and latency are not synonyms. |
| Latency rises sharply under load | Queueing/congestion candidate | idle vs loaded latency, utilization, drops | Compare same path under controlled load. |
| Voice choppy, average latency acceptable | Jitter/loss candidate | latency variation and loss | Average can hide variation. |
| Bursty destination loss | Path/RF/congestion candidate | gateway vs remote probes, counters | Local control identifies boundary. |
| CRC errors rise during traffic | Physical corruption | interface counter delta | Not ordinary capacity congestion. |
| Output drops rise at saturation | Queue pressure | utilization + output drops | Correlate timestamps. |
| Wi-Fi slow, wired control fast | RF/access path | retries, channel utilization, signal | Shared WAN is less likely. |
| One application slow, others normal | Application/destination-specific | service timing and alternate destinations | Avoid network-wide upgrades. |
| Everyone slow behind one uplink | Shared bottleneck | uplink utilization/counters | Scope identifies common path. |
| High bandwidth test but poor interactive response | Latency/jitter/queueing | RTT under load | Peak throughput alone does not describe responsiveness. |
Performance measurement rule
Measure latency, jitter, packet loss, throughput, utilization, and interface errors separately. Correlate each metric with the complaint window and traffic load. A saturated link plus output drops and load-dependent latency supports congestion; CRC errors support a different physical mechanism; a clean wired control with poor wireless results narrows toward RF/access conditions.
Large downloads slow, latency normal
Primary interpretation: Throughput/capacity/application limit. The observation should be treated as a boundary clue rather than a complete diagnosis. Capture the condition exactly as observed and compare it with the intended network design.
Evidence to collect: transfer rate, utilization, server control. Use those artifacts to confirm whether the suspected mechanism actually exists. A useful next test changes one uncertainty at a time and preserves any checkpoint that has already succeeded.
Important limit: Bandwidth and latency are not synonyms. This limit matters because many networking symptoms are shared by more than one failure mechanism. A correct answer explains both the failed behavior and the controls that still work.
Latency rises sharply under load
Primary interpretation: Queueing/congestion candidate. The observation should be treated as a boundary clue rather than a complete diagnosis. Capture the condition exactly as observed and compare it with the intended network design.
Evidence to collect: idle vs loaded latency, utilization, drops. Use those artifacts to confirm whether the suspected mechanism actually exists. A useful next test changes one uncertainty at a time and preserves any checkpoint that has already succeeded.
Important limit: Compare same path under controlled load. This limit matters because many networking symptoms are shared by more than one failure mechanism. A correct answer explains both the failed behavior and the controls that still work.
Voice choppy, average latency acceptable
Primary interpretation: Jitter/loss candidate. The observation should be treated as a boundary clue rather than a complete diagnosis. Capture the condition exactly as observed and compare it with the intended network design.
Evidence to collect: latency variation and loss. Use those artifacts to confirm whether the suspected mechanism actually exists. A useful next test changes one uncertainty at a time and preserves any checkpoint that has already succeeded.
Important limit: Average can hide variation. This limit matters because many networking symptoms are shared by more than one failure mechanism. A correct answer explains both the failed behavior and the controls that still work.
Bursty destination loss
Primary interpretation: Path/RF/congestion candidate. The observation should be treated as a boundary clue rather than a complete diagnosis. Capture the condition exactly as observed and compare it with the intended network design.
Evidence to collect: gateway vs remote probes, counters. Use those artifacts to confirm whether the suspected mechanism actually exists. A useful next test changes one uncertainty at a time and preserves any checkpoint that has already succeeded.
Important limit: Local control identifies boundary. This limit matters because many networking symptoms are shared by more than one failure mechanism. A correct answer explains both the failed behavior and the controls that still work.
CRC errors rise during traffic
Primary interpretation: Physical corruption. The observation should be treated as a boundary clue rather than a complete diagnosis. Capture the condition exactly as observed and compare it with the intended network design.
Evidence to collect: interface counter delta. Use those artifacts to confirm whether the suspected mechanism actually exists. A useful next test changes one uncertainty at a time and preserves any checkpoint that has already succeeded.
Important limit: Not ordinary capacity congestion. This limit matters because many networking symptoms are shared by more than one failure mechanism. A correct answer explains both the failed behavior and the controls that still work.
Output drops rise at saturation
Primary interpretation: Queue pressure. The observation should be treated as a boundary clue rather than a complete diagnosis. Capture the condition exactly as observed and compare it with the intended network design.
Evidence to collect: utilization + output drops. Use those artifacts to confirm whether the suspected mechanism actually exists. A useful next test changes one uncertainty at a time and preserves any checkpoint that has already succeeded.
Important limit: Correlate timestamps. This limit matters because many networking symptoms are shared by more than one failure mechanism. A correct answer explains both the failed behavior and the controls that still work.
Wi-Fi slow, wired control fast
Primary interpretation: RF/access path. The observation should be treated as a boundary clue rather than a complete diagnosis. Capture the condition exactly as observed and compare it with the intended network design.
Evidence to collect: retries, channel utilization, signal. Use those artifacts to confirm whether the suspected mechanism actually exists. A useful next test changes one uncertainty at a time and preserves any checkpoint that has already succeeded.
Important limit: Shared WAN is less likely. This limit matters because many networking symptoms are shared by more than one failure mechanism. A correct answer explains both the failed behavior and the controls that still work.
One application slow, others normal
Primary interpretation: Application/destination-specific. The observation should be treated as a boundary clue rather than a complete diagnosis. Capture the condition exactly as observed and compare it with the intended network design.
Evidence to collect: service timing and alternate destinations. Use those artifacts to confirm whether the suspected mechanism actually exists. A useful next test changes one uncertainty at a time and preserves any checkpoint that has already succeeded.
Important limit: Avoid network-wide upgrades. This limit matters because many networking symptoms are shared by more than one failure mechanism. A correct answer explains both the failed behavior and the controls that still work.
Everyone slow behind one uplink
Primary interpretation: Shared bottleneck. The observation should be treated as a boundary clue rather than a complete diagnosis. Capture the condition exactly as observed and compare it with the intended network design.
Evidence to collect: uplink utilization/counters. Use those artifacts to confirm whether the suspected mechanism actually exists. A useful next test changes one uncertainty at a time and preserves any checkpoint that has already succeeded.
Important limit: Scope identifies common path. This limit matters because many networking symptoms are shared by more than one failure mechanism. A correct answer explains both the failed behavior and the controls that still work.
High bandwidth test but poor interactive response
Primary interpretation: Latency/jitter/queueing. The observation should be treated as a boundary clue rather than a complete diagnosis. Capture the condition exactly as observed and compare it with the intended network design.
Evidence to collect: RTT under load. Use those artifacts to confirm whether the suspected mechanism actually exists. A useful next test changes one uncertainty at a time and preserves any checkpoint that has already succeeded.
Important limit: Peak throughput alone does not describe responsiveness. This limit matters because many networking symptoms are shared by more than one failure mechanism. A correct answer explains both the failed behavior and the controls that still work.
Turn three database records into a troubleshooting sequence
Step 1: Observe Large downloads slow, latency normal. Before naming a cause, write the supported boundary: Throughput/capacity/application limit. Collect transfer rate, utilization, server control. Then explicitly respect this constraint: Bandwidth and latency are not synonyms.
Step 2: Observe Latency rises sharply under load. Before naming a cause, write the supported boundary: Queueing/congestion candidate. Collect idle vs loaded latency, utilization, drops. Then explicitly respect this constraint: Compare same path under controlled load.
Step 3: Observe Voice choppy, average latency acceptable. Before naming a cause, write the supported boundary: Jitter/loss candidate. Collect latency variation and loss. Then explicitly respect this constraint: Average can hide variation.
In the Network Performance Symptoms Database context, treat this observation as evidence that must be tested against the page's specific failure boundary. Record the observed value and expected value, compare a known-good control, and choose the next artifact that can disprove the leading hypothesis. After any correction, repeat the original failed operation and confirm the related network requirement still behaves as designed.
How to study this database for AP Networking
In the Network Performance Symptoms Database context, treat this observation as evidence that must be tested against the page's specific failure boundary. Record the observed value and expected value, compare a known-good control, and choose the next artifact that can disprove the leading hypothesis. After any correction, repeat the original failed operation and confirm the related network requirement still behaves as designed.
In the Network Performance Symptoms Database context, treat this observation as evidence that must be tested against the page's specific failure boundary. Record the observed value and expected value, compare a known-good control, and choose the next artifact that can disprove the leading hypothesis. After any correction, repeat the original failed operation and confirm the related network requirement still behaves as designed.
Advanced interpretation notes
Create a baseline during healthy operation: round-trip latency to local gateway and remote control, packet loss, jitter for time-sensitive traffic, throughput where appropriate, link utilization, and interface errors/drops. During a complaint, compare against the baseline. A throughput number without the link's capacity and competing load is hard to interpret. A latency number without location is equally weak. Measure at multiple boundaries. If gateway latency is stable but remote latency rises, do not blame the local access link without additional evidence.
Evidence drill: observe “CRC errors rise during traffic.” The first boundary to evaluate is Physical corruption. Inspect interface counter delta. The critical reasoning constraint is: Not ordinary capacity congestion. Write one alternative explanation and identify a control test that would distinguish it before making a configuration change.
Verification drill: begin from “One application slow, others normal.” After correcting the supported mechanism (Application/destination-specific), repeat the original failed operation, capture service timing and alternate destinations, and confirm the result no longer matches the failure signature. Also preserve this caution during validation: Avoid network-wide upgrades.
Reason through: High bandwidth test but poor interactive response
Start with the observed clue “High bandwidth test but poor interactive response.” Its strongest initial boundary is Latency/jitter/queueing. Collect RTT under load before changing configuration. The interpretation must preserve this limitation: Peak throughput alone does not describe responsiveness. Now compare a known-good control that shares the same upstream dependencies. Record the exact values, timestamps, and expected state. If the control succeeds, narrow toward the components unique to the failed path. If it fails in the same way, widen scope to the shared dependency. After a supported correction, repeat the original test and the control, then verify that required access works and intended security or segmentation remains intact.
For the Network Performance Symptoms Database reference, the goal is not to memorize a cause beside a symptom. The goal is to select evidence that can falsify the current hypothesis. Explain what result would make Latency/jitter/queueing less likely, and where you would move next in the packet or service dependency chain. That explicit alternative is what separates evidence-based troubleshooting from confirmation bias.
Baseline note
A performance baseline should be collected when users are not reporting trouble. That healthy reference gives later latency, loss, jitter, throughput, utilization, and error measurements context. Without a baseline, a number can look unusual without actually violating the network's normal operating range.
Related evidence resources
Artifact Analysis · Troubleshooting Guide · CLI Tools · Troubleshooting Steps · Evidence Decision Lab