Core Networking · Study deck
Network Performance Lab: Measurement Setup and Terms
Packet size is the length of a packet at the layer being measured, including its headers and payload.
Packet Pete is your guide for this deck.
After studying this chapter
Learning objectives
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)
- 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
Major section
Start With the User-Visible Delay
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.
Major section
Start With the User-Visible Delay (continued)
A single speed-test peak is not a service promise.
- The lab cannot predict every future user or network.
- 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.
Major section
Overview: Performance Is A Measurement, Not A Link Label
A door sensor, vibration monitor, camera, and control loop can all share the word "network" while having different success criteria.
- Those measurements can move in different directions.
- A link can have high bandwidth and poor goodput if retransmissions dominate.
- The tool names are less important than the measurement discipline.
Major section
Overview: Performance Is A Measurement, Not A Link Label (continued)
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.
- 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.
Major section
Practitioner: Build The Performance Evidence Record
Latency should say milliseconds and whether it is one-way or round-trip.
- 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.
- Good practitioner notes use units and denominators.
- Loss should be lost packets over sent packets.
Major section
Practitioner: Build The Performance Evidence Record (continued)
The final line of the record is the engineering decision.
- 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.
- Changing one variable at a time lets the evidence point to queueing, overhead, or loss instead of mixing all three.
- If loss rises during bursts, the fix may be backoff, buffering, or admission control.
Major section
Practitioner: Build The Performance Evidence Record (continued)
Throughput should be total delivered bits per second, while goodput should be useful application payload bits per second.
- 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.
- The lab should end with a decision tied to evidence, not a vague recommendation to use a faster network.
Major section
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.
- The nominal bandwidth has not changed; the load relative to service has changed.
Major section
Under the Hood: Queues Turn Load Into Delay (continued)
LoRaWAN adds airtime and duty-cycle constraints.
- 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.
- The under-the-hood lesson is to treat averages carefully.
Major section
Under the Hood: Queues Turn Load Into Delay (continued)
TCP adds recovery and congestion-control behavior that can reduce send rate after loss.
- 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.
- Each mechanism may be correct, but each one changes the useful payload delivered per unit time.
Major section
Under the Hood: Queues Turn Load Into Delay (continued)
Wireless systems add another layer because contention and retries consume airtime.
- 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.
- 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.
Major section
Large Dataset on a Fast Link
Radio astronomy systems are a useful reminder that "fast" is a relationship between data volume and time.
- Using decimal storage units, a 10 TB data set is about 10×1012 bytes.
- 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.
Deck summary
Key takeaways
The radio name sounds impressive, but the person still waits through a queue, a service call, and a slow device reply.
- A single speed-test peak is not a service promise.
- A door sensor, vibration monitor, camera, and control loop can all share the word "network" while having different success criteria.
- A link can have acceptable average latency but unacceptable p95 latency if queues occasionally fill.
- Latency should say milliseconds and whether it is one-way or round-trip.
Retrieval practice
Recall check 1 of 2
Packet Pete says: answer from memory, then check your reasoning.
Q1A probe takes 2 ms to propagate, 3 ms to process, and 5 ms in queues on its outward path. Its reply incurs the same three delays on return. What is the round-trip time?
Show answer
Answer: C Add propagation, processing, and queuing for each direction, then add both directions.
Retrieval practice
Recall check 2 of 2
Packet Pete says: answer from memory, then check your reasoning.
Q2A LoRaWAN sensor sends a 12-byte temperature reading in an illustrative 29-byte MAC frame (12-byte payload + 13 bytes of header fields including four FOpts bytes + 4-byte MIC). What is the goodput efficiency (payload ÷ frame bytes) of this frame?
Show answer
Answer: D see answers page
Print reference
Answers
Answer key.
- C · Add propagation, processing, and queuing for each direction, then add both directions.
- D · Goodput efficiency = useful payload bytes / total transmitted bytes = 12 / 29 = 41.4%. Protocol overhead (headers, checksums, acknowledgements) reduces the fraction of each transmission that carries actual application data. Smaller payloads suffer disproportionately — in this illustration, 17 overhead bytes are 58.6% of a 29-byte frame with 12 payload bytes, but 14.5% of a 117-byte frame with 100 payload bytes.