THINK FIRST·CODE LATER

← All labs

In practice: measure whether offloading pays off

Problem

Measure a real offloading decision with your own laptop/phone hotspot and a remote machine (a lab server, a campus VM, or a free-tier cloud VM).

  1. Write a small HTTP service (Python Flask/FastAPI or Java) that receives an image (or a byte array) and runs a CPU-heavy function on it (e.g., a blur filter repeated N times, or a small ML model). Write a client that runs the same function locally.
  2. Measure: local execution time; RTT (ping), upload bandwidth (iperf3 or timing the upload), remote compute time (server-side timer) and total remote time — for at least three input sizes and two network conditions (e.g., good Wi-Fi vs. a phone hotspot, or throttled with tc on Linux).
  3. Fit the model T_remote = D/R + C/f_s + RTT to your data. How well does it predict the measured times? What is missing (TCP slow start, serialization, server queueing)?
  4. Compute the break-even bandwidth for each input size and verify it experimentally.
  5. Write a conclusion: for which input sizes and networks should your client offload? How would you make the client decide automatically at run time?

Work it out on paper, in a document or here, then compare with the model answer. Your answer stays in your browser — it is never sent to or stored on the server.