Exercise 1: A Slower Arrival Rate — Possible Solution ==================================================================== SETUP ------------------------------ ARRIVAL_INTERVAL = 8 (changed from the chapter's own 4) RESULTS ------------------------------ NO PROCESS (interval=8): 153 minutes total, 11 context switches QUEUE-BASED: 120 minutes total Overhead: 33 minutes (27.5% slower) Identical to the chapter's own interval=4 result (also 153 minutes, 11 switches, 27.5% slower). WHY THE RESULT DIDN'T CHANGE - A GENUINE STEP FUNCTION ------------------------------ Testing a range of intervals (4, 6, 8, 10, 11, 12, 15, 20) reveals the real relationship isn't gradual - it's a sharp threshold at ARRIVAL_INTERVAL = ITEM_EFFORT (10 minutes): interval=4: 153 min, 11 switches interval=6: 153 min, 11 switches interval=8: 153 min, 11 switches interval=10: 120 min, 0 switches interval=15: 120 min, 0 switches interval=20: 120 min, 0 switches Below the threshold, every single arrival interrupts the current item (since the item in progress can never finish before the next one shows up), producing the full 11 switches regardless of how far below 10 the interval is. At or above the threshold, each item finishes before the next one arrives, so there are zero interruptions at all. WHY THIS WORKS AS AN ANSWER ------------------------------ This is a more interesting and more useful finding than a gradual "less frequent arrivals = proportionally less overhead" curve would have been. It means the real, practical question for a team isn't "how much less often can requests arrive" - it's "is our request rate above or below our completion rate at all." Any request rate exceeding capacity, even slightly, produces the FULL interruption penalty; only falling at or below capacity eliminates it entirely. This maps directly onto Chapter 4's own upcoming WIP-limit material: the goal isn't to slow down requests marginally, it's to keep work-in-progress capacity from being exceeded at all.