52  Network Performance Lab

In 60 Seconds

This ESP32 lab demonstrates why bandwidth, throughput, latency, and jitter are independent metrics. A 1 Mbps link may deliver only 100 Kbps of useful data (goodput) due to protocol overhead and congestion. You will simulate network conditions, measure round-trip time, observe jitter effects on real-time IoT data, and calculate efficiency metrics hands-on.

52.1 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

Time: ~30 min | Difficulty: Intermediate | Unit: P07.C15.U08

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.

Network performance is often misunderstood. Many engineers conflate bandwidth with throughput or assume that higher bandwidth automatically means lower latency. This lab demonstrates through practical ESP32 simulation that these metrics are independent and understanding their relationships is critical for IoT system design.

52.2 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

For a LoRaWAN sensor transmitting 12-byte payloads, calculate the protocol overhead and efficiency:

LoRaWAN adds a 13-byte MAC header plus a 4-byte Message Integrity Check (MIC):

\(\text{Total packet size} = 12 \text{ (payload)} + 13 \text{ (MAC)} + 4 \text{ (MIC)} = 29 \text{ bytes}\)

Protocol overhead ratio:

\(\text{Overhead ratio} = \frac{13 + 4}{29} = \frac{17}{29} = 58.6\%\)

Efficiency (useful data / total transmission):

\(\text{Efficiency} = \frac{12}{29} = 41.4\%\)

Compare this to MQTT over TCP/IP with minimum headers (2-byte MQTT fixed header + 20-byte TCP + 20-byte IP):

\(\text{MQTT packet} = 12 + 2 + 20 + 20 = 54 \text{ bytes}\) \(\text{Efficiency} = \frac{12}{54} = 22.2\%\)

For small payloads, LoRaWAN’s dedicated IoT protocol is nearly 2x more efficient than MQTT/TCP/IP, despite LoRaWAN’s encryption overhead. This efficiency gap widens for sub-10-byte sensor readings.

Try It: Protocol Overhead Calculator
Hierarchical diagram showing bandwidth as the maximum theoretical capacity of 1 Mbps, reduced to 800 Kbps throughput due to protocol overhead, then further reduced to 600 Kbps goodput due to retransmissions and congestion, with annotations showing TCP/IP headers consume 40 bytes per packet and retransmissions can reach 5 to 20 percent
Figure 52.1: Diagram showing the relationship between bandwidth, throughput, and goodput with typical loss factors

52.3 Browser-First Lab: Test a Network Before Hardware

Start here before building the ESP32 version. The controls below let you model the same performance ideas directly in the browser: bandwidth, offered load, latency, jitter, packet loss, and goodput.

Try It: Network Performance Workbench

Build this version only after you have tried the browser workbench. The extra hardware makes latency, congestion, and button-triggered tests visible on real LEDs.

Component Quantity Purpose
ESP32 DevKit 1 Microcontroller for network simulation
Red LED 1 High latency indicator (>200 ms)
Green LED 1 Low latency indicator (<50 ms)
Yellow LED 1 Medium latency/transmission active
Blue LED 1 Congestion detected indicator
RGB LED (optional) 1 Jitter visualization (color intensity)
220 ohm Resistors 4-5 Current limiting for LEDs
Push Button 1 Trigger network tests
10K ohm Resistor 1 Button pull-down
Breadboard 1 Circuit assembly
Jumper Wires Several Connections

52.4 Circuit Diagram

Circuit diagram showing ESP32 DevKit connected to four LEDs for network performance visualization: red LED on GPIO 2 for high latency over 200 ms, green LED on GPIO 4 for low latency under 50 ms, yellow LED on GPIO 5 for active transmission, and blue LED on GPIO 18 for congestion detection, plus a push button on GPIO 15 with 10K ohm pull-down resistor for triggering network tests
Figure 52.2: Circuit diagram for network performance lab showing ESP32 with LED indicators and button input

52.5 Optional ESP32 Implementation

Use the ESP32 version after the browser workbench. Build it as a set of small behaviours so students can test each performance idea separately.

ESP32 piece What to implement How to verify it works
Bandwidth vs throughput Count total bytes sent and useful payload bytes Throughput is lower than raw bandwidth when overhead is included
Latency profile Timestamp send and receive events Serial output reports RTT and LED color follows the delay range
Jitter analysis Record several RTT samples The result shows variation, not just one average
Congestion test Increase packet rate or background load Blue congestion LED turns on and queue delay increases
Packet loss simulation Drop a controlled percentage of packets Results include retransmissions and goodput reduction

52.6 Step-by-Step Instructions

52.6.1 Step 1: Set Up the Circuit

  1. Open your preferred ESP32 development environment
  2. Add an ESP32 DevKit to your workspace or breadboard
  3. Add 4 LEDs (red, green, yellow, blue) to the breadboard
  4. Add 4 x 220 ohm resistors for current limiting
  5. Add 1 push button and 1 x 10K ohm resistor for pull-down
  6. Connect each LED through its resistor to the specified GPIO pins:
    • Red LED: GPIO 2 (high latency indicator)
    • Green LED: GPIO 4 (low latency indicator)
    • Yellow LED: GPIO 5 (transmission active)
    • Blue LED: GPIO 18 (congestion detected)
  7. Connect button: 3.3V to one leg, other leg to GPIO 15 with 10K pull-down to GND
  8. Connect all LED cathodes (short legs) to GND

52.6.2 Step 2: Upload and Run

  1. Start from the ESP32 behaviour map above rather than pasting one large program.
  2. Implement one performance feature at a time: latency LED, throughput counter, jitter samples, congestion flag, then packet loss.
  3. Compile and run after each feature so errors stay easy to isolate.
  4. Open the Serial Monitor at 115200 baud and compare each result with the browser workbench.

52.6.3 Step 3: Observe the Demonstrations

The simulator automatically cycles through educational demonstrations:

  1. Bandwidth vs Throughput: Explains why actual data rate differs from link capacity
  2. Latency Concepts: Shows components of round-trip time
  3. Jitter Analysis: Demonstrates timing variation effects
  4. Congestion Effects: Simulates network overload
  5. Full Performance Test: Runs complete measurement cycle

52.6.4 Step 4: Run Manual Tests

Press the button to trigger a full network performance test at any time. Each test:

  • Sends 20 simulated packets
  • Measures latency for each packet
  • Calculates jitter (standard deviation)
  • Simulates varying congestion levels
  • Reports comprehensive statistics

52.7 Expected Output

When running the simulation, the Serial Monitor should report a readable measurement sequence:

Stage Serial monitor should show What the LEDs should do
Startup Lab title, GPIO setup, and LED self-test status Each LED blinks during self-test
Network setup Simulated bandwidth, base latency, queue size, and packet loss LEDs turn off after setup
Ready Prompt to press the button or wait for automatic cycles All LEDs idle
Demo cycle The current topic: bandwidth, latency, jitter, congestion, or full test LED color matches the measured condition
Manual test Packet count, RTT samples, goodput, and packet-loss summary Blue LED turns on if congestion is detected
Result Performance rating and recommended tuning action LEDs reset before the next cycle
Try It: Latency Breakdown Explorer

52.8 Challenge Exercises

Challenge 1: Measure Real Wi-Fi Performance

Modify the code to measure actual network performance instead of simulation:

  1. Connect the ESP32 to your Wi-Fi network
  2. Send HTTP requests to a known server (like httpbin.org)
  3. Measure actual round-trip time using millis()
  4. Compare simulated results to real-world measurements

Hint: Use WiFi.h and HTTPClient.h libraries. The key insight is that real networks have much more variable latency than our simulation.

Challenge 2: Add Adaptive Bitrate Simulation

Implement adaptive transmission similar to video streaming:

  1. Monitor current network conditions (latency, loss rate)
  2. If conditions degrade, reduce payload size (lower “quality”)
  3. If conditions improve, increase payload size
  4. Display quality level changes on Serial Monitor

Hint: Create quality levels like “High (500 bytes)”, “Medium (200 bytes)”, “Low (50 bytes)” and switch based on measured performance.

Challenge 3: Implement Congestion Control

Add TCP-like congestion control to the simulator:

  1. Implement slow start: Begin with small transmission rate
  2. Implement congestion avoidance: Gradually increase rate
  3. On packet loss: Cut rate in half (multiplicative decrease)
  4. Visualize the congestion window (CWND) changes

Hint: Research TCP Reno’s AIMD (Additive Increase Multiplicative Decrease) algorithm.

Challenge 4: Multi-Sensor Competition

Simulate multiple IoT sensors competing for network resources:

  1. Create 5 virtual sensors, each trying to send data
  2. Implement a simple TDMA (time division) scheduler
  3. Compare performance with and without scheduling
  4. Show how fair queuing improves overall throughput

Hint: Use an array of sensor structures and cycle through them with different scheduling algorithms.

52.9 Troubleshooting

Problem Solution
LEDs not lighting Check resistor values (220 ohm) and GPIO pin assignments
No Serial output Ensure baud rate is 115200 in Serial Monitor
Button not responding Verify 10K pull-down resistor and button wiring
Simulation freezes Reduce delay times in code; ESP32 may need reset
Results seem random This is intentional – jitter simulation includes randomness

52.10 IoT Application: Why This Matters

Understanding these metrics is critical for real IoT deployments:

Application Key Metric Threshold Why
Industrial sensors Latency <100 ms Control loop stability
Video surveillance Throughput >2 Mbps Image quality
Medical devices Jitter <20 ms Consistent readings
Smart meters Goodput >90% Data completeness
Voice assistants Latency <150 ms Natural conversation
Fleet tracking Packet loss <1% Position accuracy

Common Mistake: Assuming Higher Bandwidth Reduces Latency

The Mistake: “We upgraded from 100 Mbps to 1 Gbps, so our IoT sensor latency should decrease 10x.”

Why It’s Wrong: Bandwidth (bits per second) and latency (time per packet) are independent metrics. Propagation delay (speed of light) and processing delay dominate IoT latency, not transmission time.

The Numbers:

  • 100-byte packet at 100 Mbps: transmission time = 8 microseconds

  • 100-byte packet at 1 Gbps: transmission time = 0.8 microseconds

  • Savings: 7.2 microseconds

  • Propagation delay (100 m cable): 500 nanoseconds (fixed)

  • Processing delay (router): 50-500 microseconds (fixed)

  • Queuing delay (congestion): 1-100 milliseconds (dominant factor)

Total latency: ~10-150 milliseconds, where 7.2 microseconds is negligible

The Fix: To reduce latency, minimize hops, reduce congestion, use UDP instead of TCP, or move processing closer to sensors (edge computing). Bandwidth upgrades help throughput, not latency.

52.11 Concept Review

Common Pitfalls

Networks often perform well at 10% capacity but degrade sharply at 70–80% utilisation. Fix: measure performance at multiple load levels (10%, 30%, 50%, 70%, 90%) and identify the saturation point.

An average latency of 50 ms looks acceptable, but a 99th-percentile latency of 5 seconds is unacceptable for real-time control. Fix: always report p50, p95, and p99 latency alongside the mean.

Other devices sharing the channel during measurements add uncontrolled variability. Fix: run performance measurements in a controlled environment with no other active devices on the channel, or explicitly measure and subtract background traffic.

52.12 Summary

This lab demonstrated the critical network performance metrics through hands-on simulation:

  • Bandwidth vs Throughput: Maximum capacity differs from actual achieved data rate due to protocol overhead, contention, and retransmissions
  • Latency Components: Propagation, processing, queuing, and transmission delays combine to produce the round-trip time
  • Jitter Impact: Variation in latency affects real-time applications more than average latency alone
  • Congestion Effects: Overloaded links cause exponential latency increases and can trigger congestion collapse
  • Efficiency Metrics: Goodput measures useful application data as a fraction of total transmitted data

52.13 Knowledge Check

52.14 What’s Next

Topic Chapter Description
Packet Simulator Lab Packet Simulator Lab Build and inspect packet structure hands-on, calculate checksums, and observe error detection in action
TCP Fundamentals TCP Fundamentals Understand how TCP congestion control (slow start, AIMD) manages throughput and prevents congestion collapse
Transport Protocol Comparison Transport Protocol Comparison Compare TCP vs UDP tradeoffs for latency-sensitive vs reliability-sensitive IoT applications
MQTT QoS and Sessions MQTT QoS and Sessions Apply QoS levels 0, 1, and 2 to prioritize critical sensor data and manage delivery guarantees
Network Topology Design Topologies Fundamentals Evaluate how mesh, star, and tree topologies affect latency, jitter, and fault tolerance in IoT deployments
Edge and Fog Computing Edge/Fog Introduction Reduce network latency by processing sensor data closer to the source with edge computing patterns