The Speed Test That Slowed Everything Down
A school's network administrator notices that the internet feels slow between 11:00 and 13:00. To diagnose it, she runs an automated speed test from 60 lab machines every five minutes, each test downloading a 50 MB file from an external server. The tests report excellent speeds on every machine. Meanwhile, teachers report that video calls freeze and shared drives time out. The administrator concludes the ISP is fine and the problem must be the teachers' devices. A student intern points out that the speed-test traffic itself is now part of the network load, and that the tests all target one external server.
1. Explain why the speed-test results can be accurate for each machine while the network is actually congested.
Read the worked answer
The speed test measures one flow from one machine to one external server at a moment in time. That is a narrow slice of what users experience.
Several things can be true at once:
- Each test may succeed because it briefly gets bandwidth, while the aggregate of 60 machines × 50 MB every 5 minutes adds substantial load - the measurement changes the system it measures (an observer effect).
- The tests all hit one external server, so they exercise a single path. Congestion on internal links, the shared drive server, or the path used by video-call providers would not appear.
- Video calls and shared drives are latency- and jitter-sensitive, not just bandwidth-sensitive. A link can report high throughput and still have delays that freeze calls.
So 'each machine can download fast' and 'the network is congested for interactive traffic' are compatible statements.
2. Propose a measurement plan that would actually distinguish the competing explanations, and state what result would support each.
Read the worked answer
Measure the user-facing paths, not a synthetic one:
- Latency and jitter to the actual services in use (video-call provider, shared-drive server) sampled from several locations, not just labs. High latency/jitter during 11:00–13:00 supports 'network congestion on the real paths.'
- Internal link utilization between buildings and the shared-drive server. Saturation there, with healthy external speed tests, supports 'internal bottleneck.'
- Run the synthetic test with and without the test traffic (or stagger it) to quantify the observer effect. If speeds drop when tests are disabled, the tests were masking the problem.
A well-designed diagnosis separates where the delay is (internal vs. external) from what kind of delay it is (bandwidth vs. latency). The original plan conflated both.