Project 5 — The Energy and Thermal Study

“the race is not to the swift, nor the battle to the strong” — Ecclesiastes 9:11 (ESV)

Chapter: 5 — The Budget That Governs Everything Due: End of Week 5 Weight: 7% of the course grade — the same as every weekly lab. See Appendix D. Deliverables: report.docx, measurements.xlsx, and ai-usage.txt. Nothing else, and no other filenames — the site renders these three into the document formats your section submits, so renaming them breaks the submission. Submission mechanics are in Appendix D; your environment is in Appendix A. Allowed tools: a C++17 compiler and Python 3; this chapter’s code/ files; your operating system’s own power, frequency, and thermal interfaces; vendor specification pages and architecture reference manuals for any external figure. Optionally (never required) an Android device per Workbench D. AI policy — explain, never source. Use a model freely to explain a concept, check your algebra, or improve your prose. Never use one as a source for a number. Every thermal design power, battery capacity, nominal cell voltage, clock, or device figure in this report must trace to a vendor specification page, an architecture reference manual, or your own measurement, and must be cited inline. An uncited external figure scores zero on the citation line; a fabricated one fails the integrity line and the project. Your ai-usage.txt names every model you used and exactly what it did.

On the numbering. There is no Project 4 — Week 4 was the checkpoint week, carrying the auto-graded cumulative checkpoint and the Placement Practical instead of a weekly lab. The projects in this course run 1, 2, 3, then 5. This is 5.

The Setup

A Lutheran relief agency runs mobile health clinics in three regions. Their field workers carry a rugged handheld: it records patient encounters, runs an on-device translation model so that no patient’s speech ever leaves the device, and holds a satellite-positioning fix for logistics. There is no mains power in the field. A shift is ten hours, and the device must survive it.

The agency has a procurement decision in front of them and a vendor’s data sheet on the table. The data sheet leads with a benchmark score. It is a real score, honestly obtained. The agency’s operations director — who has been burned before — has asked one question and will not be talked out of it:

“Will it still be doing that in the ninth hour?”

You are the architect they trust. Your job is not to pick a device; you do not have the devices. Your job is to build the analysis that would let anyone pick correctly — to show, with arithmetic they can check, what an energy and thermal budget actually looks like, what an operating policy costs in joules, and which of the vendor’s numbers describe a device in a hand at hour nine rather than a device on a bench at second thirty.

The clinical workload is the interesting part, and it is exactly this week’s material. A patient encounter is bursty: a few seconds of speech capture, a short burst of on-device inference, a database write, then minutes of nothing while a human being talks to another human being. But when the clinic gets busy, those bursts stack up into something that looks a lot more like a sustained load — and a sustained load on a sealed rugged handheld with no fan is a thermal event, not just a compute one.

Endurance is the whole product here. A device that is fastest at 9 a.m. and unusable at 4 p.m. has failed the person it was bought for. Your report is what stands between the operations director and a number that is true about a situation nobody in the field will ever be in.

Setup (the starter)

Everything you need ships in this chapter’s code/ folder, and everything runs on Workbench B — a browser dev environment with no install and no admin rights — as well as on a local machine.

• code/energy_model.cpp — the joules-per-task model over a set of voltage/frequency operating points. Finds the efficiency knee; evaluates race-to-idle over a window. Flags: --cycles, --platform, --idle, --window.
• code/thermal-soak.csv — a fifteen-minute sustained-load soak of a modeled phone-class SoC. Its first line declares it synthetic. Documented in Appendix B.
• code/throttle_analysis.py — reads a soak log, finds the throttle onset, computes the sustained-to-peak ratio, and prints the honesty line. Flags: --window, --tail.
• code/battery.py — mAh↔Wh↔joules conversion plus a runtime estimator over concurrent subsystem draws. Flags: --mah, --volts, --profile, --draw, --floor.

g++ -std=c++17 -O2 -o energy_model code/energy_model.cpp
./energy_model
python3 code/throttle_analysis.py
python3 code/battery.py

If you did the reps, you have already run every one of these and drafted the spine of Part 3. Good. That was the point.

Learning Targets

By completing this project you will demonstrate that you can:

• Compute joules per task across a set of operating points, locate the efficiency knee, and explain the two competing terms that produce it.
• Show that the knee is a property of the whole platform by moving it deliberately and explaining the movement physically rather than by citing a program’s output.
• Read a thermal soak log: identify the throttle onset, the sustained state, and the sustained-to-peak ratio, and state how each depends on the analysis window you chose.
• Run a real sustained-load experiment on hardware you actually have, report it per Appendix C with medians, dispersion, and full stated conditions, and interpret a negative result honestly.
• Choose and defend an operating policy in joules against a stated delivered-work target, and check that policy against the thermal envelope rather than only against the energy arithmetic.
• Distinguish modeled from measured data in your own report, and state precisely what you could not measure and what you would need in order to.

Normal Tier

Goal: Produce report.docx and measurements.xlsx containing three parts — the energy model, the thermal analysis, and the defended operating policy — plus ai-usage.txt.

Every requirement below is completable on Workbench B alone. Nothing here needs a phone, a power meter, or administrator rights.

Required features

1. Part 1 — The efficiency knee, by hand and by program. a. Build and run code/energy_model.cpp at its defaults. Reproduce the operating-point table in report.docx and identify the knee. b. Reproduce at least two rows of that table by hand, showing the arithmetic: t = N/f, E_dyn = k·V²·N, E_stat = (leakage + platform)·t. Your numbers must match the program’s to three decimal places, and if they do not, find out why before you write anything else. c. Explain in your own words, in no more than five sentences, why frequency cancels out of the dynamic-energy term and what that means for the claim “run everything as slowly as possible.” d. State explicitly that the operating points are a synthetic teaching model, not a datasheet, and say in one sentence what that limits about every conclusion in Part 1.

2. Part 2 — Move the knee, and say why it moved. Run the model under at least two altered conditions — for example --platform 3.0 (screen lit, radio active), --platform 0.2 (deep background), or --window set to a deadline the knee cannot meet. For each:

   • Report the new knee and the new joules-per-task at that knee.
   • Explain the movement physically: which term in the energy equation changed, and why that shifts the minimum. “The program printed 2400” is not an explanation.
   • State one real workload from the relief-agency scenario that matches each condition.

3. Part 3 — The soak log and the honesty line. a. Run code/throttle_analysis.py on code/thermal-soak.csv at defaults, then at at least two other --window/--tail settings. b. Report the throttle onset, the sustained clock and power, and the sustained-to-peak ratio for each setting — and then the graded observation: how much did the reported ratio move, and what does that imply about a published ratio whose analysis window is not stated? c. Name the three phases of the curve and give the second at which each begins. d. State plainly that this dataset is synthetic teaching data, modeled on published behaviour and not a measurement of any specific product, and say what that limits — specifically, which of your conclusions would survive being wrong about the model and which would not.

4. Part 4 — Your own sustained-load experiment. Run a real sustained load on hardware you actually have, following Appendix C’s soak protocol. Rep 8’s portable probe is the reference implementation; you may use any load you can describe precisely.

   • Run for at least ten minutes, sampling delivered work at least every ten seconds.
   • Commit the raw output. Not a summary — the raw numbers.
   • Report opening rate, final rate, the ratio, and the sample at which the rate first dropped.
   • A negative result is a valid result and is graded the same. If your machine did not throttle, say so, give the two most plausible reasons, and say what you would need in order to distinguish them. On a shared cloud instance, state explicitly that you cannot separate your own throttling from a noisy neighbour.

5. Part 5 — The operating-policy decision (the graded core). The agency’s device must deliver a stated amount of work within a stated window. Use this target, or a clearly-stated variant of it: 1,200 task-quanta of the model’s work, completed within an eight-hour shift, on a device whose deep-idle draw you state.

   • Choose an operating policy: race-to-idle at a high point, run at the knee, or a stated middle. Compute total joules for at least three candidate policies using energy_model.cpp, showing the flags you passed.
   • Convert the winner into a share of a real battery using code/battery.py with a capacity and nominal voltage you cite from a primary source. If you cannot find a nominal voltage from a primary source, say so and reason structurally instead of inventing one — that is the correct answer, not a gap.
   • Check the policy against heat. Using Part 3’s sustained-to-peak ratio, state whether your chosen operating point is sustainable across the shift or whether the device would throttle out from under it. If it would, revise the policy and redo the arithmetic. A policy that is optimal in joules and impossible in watts is a wrong answer.
   • Write the verdict: the policy, the joules, the assumption you are least sure of, and the single measurement that would change your mind.

6. measurements.xlsx — the measurement log. Per Appendix C: for every run, what you ran, on what, how many repetitions, the median, the dispersion, and the conditions — plugged in or on battery, ambient, machine on a hard or soft surface, anything else running. A single number with no repetition count and no conditions earns nothing on this line, however correct it is.

7. “What I could not measure and what I would need.” A required, explicit section of report.docx. Name at least three things — for the relief-agency question, the honest list starts with actual device power, actual skin temperature, and the real workload’s duty cycle — and for each say what instrument, access, or dataset would let you get it.

8. Citations and ai-usage.txt. Every external figure carries an inline citation to a primary source. ai-usage.txt names each model and version you used, what you used it for, and — the part people skip — where you overrode it or caught it being wrong.

Normal-tier rubric (out of 100)

Medium Tier (+up to 25% extra credit)

M1. The full battery budget for the field device

Build a ten-hour shift budget for the relief agency’s handheld in a new section of report.docx, using code/battery.py.

• Cite a real device’s battery capacity and nominal cell voltage from the manufacturer’s own specification page. Convert to watt-hours and to joules yourself, showing the arithmetic. If the nominal voltage is not published — and often it is not — say so, and present the analysis parametrically across the 3.7–3.9 V range instead of picking a number.
• Construct a duty-cycle model of the clinical workload: what fraction of the shift is idle with the screen off, what fraction is a patient encounter, what fraction is sustained inference. State your assumptions as assumptions. Use --draw to override the shipped subsystem values where you can justify a different one.
• Report the hours of runtime for each mode and for the blended shift, and identify the dominant subsystem in each.
• Then the design question: name the one change that most improves shift endurance, and quantify it. It is very likely not a change to the SoC. Say why.

M2. Sensitivity, not point estimates

Every number in M1 rests on an assumption. Pick the three assumptions your conclusion is most sensitive to and vary each by ±30%, reporting how the shift-endurance answer moves. Then state which single assumption, if wrong, would flip your recommendation — and how you would go about checking it. A recommendation that survives a sensitivity analysis is worth ten that do not.

Hard Tier (+up to 25% additional extra credit)

H1. The envelope memo (the judgment piece)

Write a memo, a page at most, as a new section of report.docx titled “Envelope or Efficiency.” You are advising the silicon team for the relief agency’s next-generation handheld. You may have exactly one of the following, and not both:

• A 20% larger thermal envelope — a better spreader, more chassis mass, a design that gets heat out faster.
• A 15% improvement in performance-per-watt at every operating point.

Choose one. Defend it with arithmetic, and answer all four of these:

1. Which product does each option favour, and why? Show the effect of each on peak, on the sustained state, and on shift endurance separately — they do not move together. Use Part 3’s numbers to make the thermal argument quantitative.
2. What does each option cost that a spec sheet will not show? Mass, thickness, cost, yield, schedule, and the fact that one of them changes a number the reviewers publish while the other changes a number the field worker experiences.
3. What would you have to measure on real hardware to know you were right? Be specific: the instrument, the protocol, the number of repetitions, the conditions, and the result that would falsify your recommendation.
4. What is the honest uncertainty in your recommendation? Not a hedge — a stated confidence with a reason.

A memo that picks the option with the bigger percentage fails. A memo that says “it depends” and stops fails. The grade is in the defended commitment: you must choose, for a named product and a named workload, and be able to say what would change your mind. That last move — a firm recommendation with an explicit falsifier — is what a model cannot do for you, because it requires owning the consequence.

H2. Optional, Workbench D — the device measurement

Never required. There is a complete non-device path in H1, and H1 is graded identically without this section.

On an Android device with developer options and the debug bridge, run a sustained load and capture the platform’s own thermal view before, during, and after:

adb shell dumpsys thermalservice

Log the device, the ambient temperature, whether it was charging, whether it was in a case, and how long you soaked it. Report what the thermal status ladder actually did, and compare its shape to thermal-soak.csv — naming at least one place where the modeled curve and the real one disagree, and why the model was wrong there. Do not report a device’s power or temperature figures as general facts about that product; they are one measurement of one unit under one set of conditions, and your report must say so.

Submission

report.docx, measurements.xlsx, and ai-usage.txt, in the form your section requires — see Appendix D. Include your raw soak output as a fenced block or an attached data file referenced from measurements.xlsx; do not paste a summary in place of data.

Open report.docx with this header block, filled in:

# Project 5 — The Energy and Thermal Study

**Tier targeted:**        Normal / Medium / Hard
**Workbench:**            L / B / D  (and what that limited)
**Efficiency knee found:** ____ MHz at ____ J/task (default conditions)
**Knee moved to:**        ____ MHz under ____ (and the physical reason)
**Throttle onset:**       t = ____ s;  sustained/peak = ____ (window ____ / tail ____)
**My own soak:**          opening ____ , final ____ , ratio ____ , conditions ____
**Policy chosen:**        ____ , at ____ joules for the stated target
**Sustainable?**          yes / no, and the thermal reasoning
**Least-certain assumption:** ____
**What would change my mind:** ____
**AI usage:**             see ai-usage.txt

Hints (Read Before You Begin)

• Do the hand arithmetic first, every time. If your hand numbers and the program’s disagree, you have found either a bug in your algebra or a misunderstanding of the model, and both are worth more to you right now than a finished report.
• “The program printed X” is never an explanation. Every number in Part 2 needs a sentence about which physical term moved. Graders can tell the difference instantly, and so can procurement directors.
• Choose your analysis window before you look at the answer. Deciding --tail after you have seen which value flatters your conclusion is exactly the failure mode Week 8 is about. Write the window down first, then run.
• A negative result is data. “My laptop did not throttle in ten minutes” is a real finding with real causes. Reporting it honestly, with the reasons, earns full marks. Quietly re-running until you get a curve you like does not.
• Sustained beats optimal. A policy that minimises joules but cannot be held for the shift is the wrong policy. Check the envelope before you commit to the arithmetic, not after.
• The SoC is probably not your answer. Run battery.py early. On a device with a screen on, the display and the radio are budget-scale actors. If your recommendation is “make the SoC more efficient,” check whether the SoC is even a quarter of the budget first.
• Cite, or say you cannot. “I could not find a primary source for the nominal cell voltage, so the analysis is presented parametrically across 3.7–3.9 V” is a strong sentence in a graduate report. A confident 3.85 V with no source is a weak one, and a fabricated one is a failing one.

What Mastery Looks Like (Beyond the Rubric)

A great Project 5 reads like an analysis a procurement director could act on and a skeptical engineer could not poke a hole in. The arithmetic is checkable by hand. The knee moves for a reason you can state in a sentence about physics. The soak analysis names its window before it names its ratio. The operating policy is a commitment, not a survey — one policy, one number of joules, one stated assumption that could sink it, and one measurement that would settle it. And the section on what could not be measured is longer and more specific than most students expect, because the author knows exactly where their model stops and the world begins.

The tell of a weak report is a number without conditions. The tell of a strong one is a conclusion that says how it could be wrong.

Coach’s Note — The operations director’s question — “will it still be doing that in the ninth hour?” — is the whole discipline in eight words. Every architect eventually meets a version of it: the customer who does not care about your peak, only about your ninth hour. Your value in that room is not that you can run a benchmark. It is that you can say, with arithmetic behind you, which of the vendor’s true numbers describe the ninth hour and which describe the first minute. Nobody else in that room can do it. That is the job.

When You’re Done

1. Re-read every number in report.docx and ask of each: measured, modeled, or cited? Label it. Any number that is none of the three does not belong in the document.
2. Confirm both datasets are declared synthetic where they are synthetic, and that you have said what that limits — not just that it is true.
3. Check that measurements.xlsx gives a repetition count, a median, a dispersion, and the conditions for every single run. Any row missing conditions is a row a stranger cannot reproduce.
4. Read Part 5 as if you were the operations director. Can you tell what to buy, and why, and what would change the answer? If not, sharpen it.
5. (Hard) Re-read the memo and confirm it commits. Strip every sentence that hedges without a number behind it.
6. Submit, then read Chapter 6 — wiring the system together, where the interconnect decides who waits and the modem turns out to be a computer running its own operating system next to yours.

A theological footnote. “The race is not to the swift, nor the battle to the strong” (Ecclesiastes 9:11, ESV). The Preacher is not scolding the fast; he is reporting an observation that engineers make in a different vocabulary every day — that capacity and outcome come apart, and that the gap between them is where honest work lives. This project asks you to measure that gap and then to publish it, including the parts of it that make your own analysis look less certain. That is harder than it sounds, because a peak number is genuinely true and genuinely flattering, and the temptation is never to lie but simply to omit the conditions. The field worker in the ninth hour cannot check your work. Reporting the number she needs rather than the number that wins the comparison is a small, concrete act of loving a neighbour you will never meet — which is, in the Lutheran reading, most of what vocation actually is. Design for the fourth hour. Publish the honest number. Let the peak take care of itself.

See you next week.