27 Network Performance Lab: Measurement Setup and Terms
27.1 Start With the Decision
A speed test number means little without packet size, path, load, and clock. The lab first fixes the setup and names each metric.
27.2 Route Overview
This is part 1 of 2. Continue with Network Performance Lab: Calculations and Experiments.
27.3 Part Objectives
- Set up repeatable network performance measurements.
- Distinguish throughput, latency, jitter, and loss.
27.4 Start With the User-Visible Delay
Measure the User’s Wait, Not the Link’s Label
Picture a door control that uses a fast wireless link yet takes three seconds to show that a command worked. The radio name sounds impressive, but the person still waits through a queue, a service call, and a slow device reply.
Bandwidth is the amount of data a link can carry in a set time. Latency means delay from a starting event to a chosen finish. A protocol is a shared set of message rules. State which one the user or system needs, then mark the exact start and end of the measurement.
Run a quiet baseline and repeat it under realistic load. Measure several trials, keep the middle and worst useful result, and note loss, retries, path, message size, time, and device state. Then add one fault or competing flow. A single speed-test peak is not a service promise.
The lab cannot predict every future user or network. Record the tested conditions and the level that triggers review. The deeper sections separate delay, rate, loss, and variation so the team can fix the limiting step rather than blame the link label.
Network performance matters when a person, machine, or control loop notices the delay, loss, jitter, or throughput limit. A fast link label is not enough; the useful question is whether the application still meets its promise under real load.
This lab turns performance into evidence. Measure what the application receives, connect it to queues and overhead, then decide whether the bottleneck is capacity, contention, latency, loss, or test design.
The mathematical gist. Propagation delay and path loss are different ledgers. In the chapter’s n=3.3 factory model, obstruction adds 10(3.3−2)log10(d) dB; it reaches the illustrative 14 dB sensitivity gap between 54 and 12 Mbps at 11.9 m, long before nanosecond-scale travel time becomes the bottleneck.
27.5 Learning Objectives
By completing this lab, you will be able to:
- Differentiate bandwidth from throughput: Explain why a 1 Mbps link may only deliver 100 Kbps of actual data due to protocol overhead and contention
- Measure and interpret latency: Calculate round-trip time (RTT) and decompose its components (propagation, processing, queuing)
- Analyze jitter patterns: Evaluate how latency variation affects real-time IoT applications such as industrial control and sensor fusion
- Demonstrate congestion effects: Apply network simulation to compare packet delivery under normal and overloaded traffic conditions
- Calculate efficiency metrics: Compute goodput as a fraction of total transmitted data and compare protocol overhead ratios
Network performance measures how quickly and reliably data moves between devices. Think of it like measuring traffic flow on a road — you care about speed (how fast cars go), throughput (how many cars pass per hour), and delays (how long you wait at intersections). These same ideas apply when IoT sensors send data to the cloud.
- Start With the User-Visible Delay
- In 60 Seconds
- Phoebe’s Field Notes: Why 54 Mbps Wi-Fi Measures 12 Mbps on the Floor
- For Beginners: Network Performance
- Overview: Performance Is A Measurement, Not A Link Label
- Practitioner: Build The Performance Evidence Record
- Under the Hood: Queues Turn Load Into Delay
- Key Concepts Explained
- Large Dataset on a Fast Link
- Network Performance Terms
27.6 Overview: Performance Is A Measurement, Not A Link Label
A network is not fast because its label says 1 Mbps, 54 Mbps, or 1 Gbps. It is fast enough only if the measured path delivers the application’s useful data within the time, loss, and jitter budget that the IoT job needs. A door sensor, vibration monitor, camera, and control loop can all share the word “network” while having different success criteria.
For a learner, the important shift is simple: bandwidth is the ceiling, throughput is what the path actually carries, latency is how long one exchange waits, jitter is how much that wait moves around, and goodput is the part the application can use. Those measurements can move in different directions. A link can have high bandwidth and poor goodput if retransmissions dominate. A link can have acceptable average latency but unacceptable p95 latency if queues occasionally fill. A link can deliver every packet and still fail a control task if the packets arrive after the decision deadline.
A performance lab should start from the application budget, then use latency, jitter, goodput, and utilisation evidence to identify the bottleneck.
This is why the lab starts with a measurement record instead of a speed label. In production IoT work, the same pattern appears across tools: ping can expose round-trip timing, iperf3 can estimate throughput where the endpoints support it, Wireshark can show retransmissions and packet sizes, and MQTT broker logs can show publish timing and disconnects. The tool names are less important than the measurement discipline. State the application budget first, measure the path under a defined load, then decide whether the observed margin is enough for the job.
The overview lesson is that performance is a contract between the application and the path. The path includes radio airtime, wired hops, queues, gateways, brokers, cloud services, and application processing. A good lab makes each part visible enough that students can say which metric failed and why, not just that “the network is slow.”
27.7 Practitioner: Build The Performance Evidence Record
A useful lab record names the tested flow, the offered load, the measured result, and the decision. For each run, capture packet size, payload size, packet rate, link condition, p50 and p95 latency, jitter range, loss rate, retransmissions, throughput, goodput, and the observed bottleneck. The record should also state the measurement point: device-to-gateway, gateway-to-broker, broker-to-application, or end-to-end. Without that boundary, a timing number cannot explain where the delay came from.
Run at more than one load point. A path that looks healthy at 10 percent utilisation can fail near saturation, and a low average latency can hide p95 delays that break control loops or real-time dashboards. Use a small load ladder instead of a single run: for example, baseline idle traffic, expected normal traffic, expected burst traffic, and a deliberate overload case. Keep the payload and protocol constant while you raise packet rate, then keep the packet rate constant while you change payload size. Changing one variable at a time lets the evidence point to queueing, overhead, or loss instead of mixing all three.
Good practitioner notes use units and denominators. Latency should say milliseconds and whether it is one-way or round-trip. Jitter should say how it was calculated, such as max-minus-min, standard deviation, or p95-minus-p50. Loss should be lost packets over sent packets. Throughput should be total delivered bits per second, while goodput should be useful application payload bits per second. That distinction matters in IoT because protocol headers, acknowledgements, security tags, keep-alives, retransmissions, and padding can all consume airtime without delivering new sensor data.
The final line of the record is the engineering decision. If p95 latency is above the control deadline, the fix may be lower packet rate, smaller payloads, local edge processing, a different radio setting, or a separate traffic class for control messages. If goodput is low but latency is stable, the fix may be packet aggregation, compression, or a protocol with lower overhead for small payloads. If loss rises during bursts, the fix may be backoff, buffering, or admission control. The lab should end with a decision tied to evidence, not a vague recommendation to use a faster network.
27.8 Under the Hood: Queues Turn Load Into Delay
When offered load approaches the service rate, packets wait in buffers before they can be transmitted. That queueing delay changes the distribution of latency, not just the average. If buffers overflow, packet loss and retransmissions can add still more load. This is the mechanism behind the common lab observation where everything looks normal for a while, then latency suddenly becomes unstable as the packet rate rises.
The underlying reason is that a queue is a waiting room with a service rate. If packets arrive slower than the link or processor can serve them, the queue drains between arrivals and delay stays bounded. If packets arrive at about the same rate they can be served, small bursts create waiting time. If packets arrive faster than service for long enough, the queue grows until packets are dropped or deadlines are missed. The nominal bandwidth has not changed; the load relative to service has changed.
This is why goodput can fall while bandwidth is unchanged. The physical or radio link still has the same nominal capacity, but overhead, contention, retries, and queueing consume part of the path before useful application bytes arrive. Wireless systems add another layer because contention and retries consume airtime. TCP adds recovery and congestion-control behavior that can reduce send rate after loss. MQTT QoS levels add acknowledgements and state tracking. LoRaWAN adds airtime and duty-cycle constraints. Each mechanism may be correct, but each one changes the useful payload delivered per unit time.
The under-the-hood lesson is to treat averages carefully. Average latency can hide a long tail, and the tail often decides whether an IoT workload is safe. A dashboard may tolerate a late reading; a control loop may not. A temperature logger may survive a dropped sample; a command channel may require acknowledgement, retry, and idempotent receiver behavior. The performance lab connects these internal mechanisms to visible measurements: offered load, queue delay, loss, retransmission, jitter, and goodput. Once students can read those signals together, they can reason about bottlenecks instead of guessing from the link label.
27.9 Key Concepts Explained
Before diving into the lab, review the terminology:
| Metric | Definition | IoT Example |
|---|---|---|
| Bandwidth | Maximum theoretical data rate (bits/second) | LoRaWAN SF7: 5.47 Kbps max |
| Throughput | Actual measured data rate achieved | LoRaWAN real-world: 2-3 Kbps |
| Latency | Time for data to travel from source to destination | MQTT publish: 50-200 ms |
| Jitter | Variation in latency over time | Video stream: +/-15 ms |
| Goodput | Application-layer useful data rate | Sensor reading: 100 bytes/min |
| Overhead | Protocol headers, retransmissions, ACKs | TCP/IP: 40+ bytes per packet |
Radio astronomy systems are a useful reminder that “fast” is a relationship between data volume and time. Suppose a telescope archive needs to move a 10 TB data set to a processing site over a dedicated 10 Gbps optical link.
Convert the link first:
Using decimal storage units, a 10 TB data set is about bytes. The ideal transfer time is therefore:
If a vehicle can carry the same disks across roughly 700 km in 10 hours, the network link wins for this case even before counting handling time. The lesson is not that networks always beat physical transport. It is that the engineering record must state the units, usable throughput, payload size, overhead, and deadline before deciding which path is actually faster.
27.10 Continue to the Next Part
Carry this evidence into Network Performance Lab: Calculations and Experiments, which begins with Putting Numbers to It.