Fix mathematical errors in Theorems 4, 5, 10 and IT example

Corrections:
- Theorem 4: Restated from "maximizes slowdown inequality" (wrong) to
  "uniquely assigns max completion time to largest task" (correct).
  SPT actually compresses slowdown variance; harm is in absolute delay.
- Theorem 5: Completely rewritten. Old claim that LPT minimizes slowdown
  variance was backwards (verified: tasks [1,5,10] give SPT var=0.06,
  LPT var=42.2). New theorem correctly states SPT concentrates absolute
  delay on the largest task.
- Theorem 10: Removed draft language ("Wait —"), corrected cross-term
  analysis. Old claim that SPT is Pareto-dominated when p_H > 8p_L was
  wrong (verified: n_H=2,n_L=2,p_H=10,p_L=1 gives D_SPT=275 < D_pri=283).
  Replaced with correct WSJF exchange argument.
- IT example: Fixed PWCT arithmetic (9.225→10.2, 6.633→10.167). Added
  honest discussion that aggregate PWCT fails to distinguish schedules;
  per-priority-class metrics are needed.
- Section 5: Added caveat that Little's Law batch-case application is
  not straightforward; clarified what Theorem 2 actually proves.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
Mortdecai
2026-03-28 17:18:31 -04:00
parent 3edc5d33b2
commit 574eca5b27
+133 -122
View File
@@ -135,17 +135,23 @@ a 10-hour task.
## 5. Connection to Little's Law ## 5. Connection to Little's Law
Little's Law states $L = \lambda W$, where $L$ is the average number of tasks Little's Law states $L = \lambda W$, where $L$ is the time-averaged number
in the system, $\lambda$ is the arrival rate, and $W$ is the average time a of tasks in the system, $\lambda$ is the arrival rate, and $W$ is the
task spends in the system. average time a task spends in the system.
For a stable system, $L$ and $\lambda$ are determined by arrival and service In a *steady-state* queueing system with fixed arrival and service rates,
rates — not by scheduling policy. Therefore $W = L / \lambda$ is $\lambda$ and the long-run service rate are determined by the workload, not
**schedule-invariant** when measured correctly (i.e., weighted by the quantity by scheduling policy. Little's Law then tells us that $L$ and $W$ are
being served). linked, but in the batch case (all $n$ tasks present at time 0), $L$ and
$W$ are both schedule-dependent: $\bar{C} = W$, and
$L = \sum C_i / \sum p_i$, both of which SPT minimizes.
SPT appears to violate this only because the unweighted statistic counts The invariance we proved in Theorem 2 is more specific: *work-weighted*
*completions* rather than *work*, systematically underweighting large tasks. mean completion time $\bar{C}_w$ is constant across schedules. This
corresponds to measuring the system from the perspective of "how long does
a unit of *work* wait" rather than "how long does a *task* wait." The
unweighted statistic measures the latter and is gameable precisely because
it counts completions rather than work.
--- ---
@@ -196,44 +202,34 @@ Client satisfaction is inversely related to slowdown: a client who waits
2x their task size is more satisfied than one who waits 20x, regardless of 2x their task size is more satisfied than one who waits 20x, regardless of
the absolute times involved. the absolute times involved.
**Theorem 4 (SPT Maximizes Slowdown Inequality).** Among all schedules, **Theorem 4 (SPT Uniquely Maximizes Completion Time of the Largest Task).**
SPT maximizes the difference between the maximum and minimum slowdown ratios. Among all schedules, SPT is the unique policy that assigns the maximum
possible completion time ($\sum p_i$) to the largest task.
**Proof.** **Proof.**
Under any schedule $\sigma$, the task in position $k$ has completion time SPT sorts tasks in ascending order of $p_i$, placing the largest task
$C_{\sigma(k)} = \sum_{j=1}^{k} p_{\sigma(j)}$ and slowdown: $p_{\max}$ in the last position. The last task in any schedule has
completion time $\sum_{i=1}^{n} p_i$, which is the maximum completion time
any individual task can receive. Therefore, under SPT:
$$S_{\sigma(k)} = \frac{\sum_{j=1}^{k} p_{\sigma(j)}}{p_{\sigma(k)}}$$ $$C_{\max\text{-task}}^{\text{SPT}} = \sum_{i=1}^{n} p_i$$
Under SPT, the last task (position $n$) is the largest, $p_{\max}$, with: Under any schedule that does not place $p_{\max}$ last, the largest task
completes strictly before $\sum p_i$. SPT is the unique schedule (among
those ordered by processing time) that assigns this worst-case completion
time to the largest task.
$$S_n^{\text{SPT}} = \frac{\sum_{i=1}^{n} p_i}{p_{\max}}$$ Note on slowdown: SPT actually *compresses* slowdown ratios ($S_i = C_i / p_i$)
because larger tasks in later positions have large denominators that absorb
the accumulated sum. For example, with tasks $[1, 5, 10]$:
The first task is the smallest, $p_{\min}$, with: - SPT: slowdowns $[1, 1.2, 1.6]$ — low variance
- LPT: slowdowns $[1, 3, 16]$ — high variance
$$S_1^{\text{SPT}} = \frac{p_{\min}}{p_{\min}} = 1$$ SPT's harm to large-task clients is not visible in the slowdown ratio. It is
visible in **absolute completion time**: the largest task finishes last, at
The slowdown range under SPT is: $\sum p_i$, while under any other ordering it finishes earlier. $\blacksquare$
$$\Delta S^{\text{SPT}} = \frac{\sum p_i}{p_{\max}} - 1$$
Now consider the reverse schedule (Longest Processing Time first, LPT).
The largest task goes first with slowdown 1. The smallest task goes last:
$$S_n^{\text{LPT}} = \frac{\sum p_i}{p_{\min}}, \quad S_1^{\text{LPT}} = 1$$
While LPT has a larger maximum slowdown, its minimum is also 1. The critical
difference is *which clients* suffer. Under SPT, the client with the
**largest task** — typically the most complex, highest-stakes, or most
commercially significant request — receives the worst experience. Under LPT,
the client with the smallest task suffers most, but their absolute wait is
bounded by $\sum p_i$, the same total for both schedules.
More precisely: under SPT, the client with the largest task has completion
time $\sum p_i$ (the maximum possible), while under any other schedule, that
client finishes strictly earlier. SPT **uniquely minimizes the satisfaction
of the highest-effort client**. $\blacksquare$
**Corollary 4.1.** A team optimizing unweighted mean completion time will **Corollary 4.1.** A team optimizing unweighted mean completion time will
systematically deliver the worst experience to clients with the most systematically deliver the worst experience to clients with the most
@@ -244,42 +240,40 @@ The only way to lower the unweighted average is to complete more small tasks
early, which necessarily means completing large tasks later. The metric early, which necessarily means completing large tasks later. The metric
improves *because* high-effort clients are deprioritized. improves *because* high-effort clients are deprioritized.
### 7.2 The Fairness Benchmark: Proportional Slowdown ### 7.2 The Absolute Delay Burden
A **fair** schedule is one where all clients experience equal slowdown: The slowdown ratio $S_i = C_i / p_i$ might suggest SPT is *fair* — it
compresses slowdown variance by giving everyone a ratio close to 1. But
this obscures the real cost. The correct measure of burden is the
**absolute delay** experienced by each task:
$$S_i = S_j \quad \forall \, i, j$$ $$\Delta_i = C_i - p_i$$
This means every client waits the same multiple of their task's inherent This is the time a task spends waiting for other tasks, independent of its
processing time. A 1-hour task might wait 2 hours; a 10-hour task waits 20 own size. Under any sequential schedule, the total delay across all tasks
hours. The ratio is the same. is schedule-dependent (it equals $\sum C_i - \sum p_i$), and SPT minimizes
this total. But the *distribution* of delay matters.
**Theorem 5 (Proportional Scheduling).** The unique schedule achieving equal **Theorem 5 (SPT Concentrates Delay on the Largest Task).** Under SPT, the
slowdown for all tasks is to order tasks so that each task's completion time largest task bears more absolute delay than under any other schedule.
is proportional to its processing time:
$$C_i = S \cdot p_i \quad \text{where } S = \frac{\sum p_i}{\sum p_i} \cdot \frac{\sum_{j} p_j}{p_i} \text{ ... }$$ **Proof.** Under SPT, the largest task is in position $n$ with:
In general, equal slowdown is not achievable with sequential scheduling $$\Delta_{\max\text{-task}}^{\text{SPT}} = C_n - p_n = \sum_{i=1}^{n-1} p_i$$
(it requires parallel or proportional-share scheduling). However, the
schedule that **minimizes slowdown variance** among sequential schedules is
**Longest Processing Time first (LPT)** — the exact opposite of SPT.
**Proof sketch.** Under LPT, large tasks go first and receive slowdown This is the sum of all other tasks' processing times — the maximum possible
close to 1. Small tasks go last and accumulate more slowdown, but their delay for any single task. Under any schedule where the largest task is not
absolute wait is still bounded. The variance in slowdown ratios is minimized last, its delay is strictly less than $\sum_{i \ne \max} p_i$.
because the tasks with the largest denominator ($p_i$) also have the
largest numerator ($C_i$), keeping the ratios compressed.
Under SPT, the opposite occurs: tasks with the smallest denominator get the Meanwhile, SPT gives the smallest task zero delay ($\Delta_1^{\text{SPT}} = 0$).
smallest numerator, and tasks with the largest denominator get the largest The entire queuing burden is shifted from small tasks to large tasks.
numerator, maximizing the spread. $\blacksquare$
Formally, for any two schedules $\sigma_1$ (SPT) and $\sigma_2$ (LPT): The tension is this: SPT minimizes total delay (good for aggregate
efficiency) by concentrating delay onto the tasks best able to "absorb" it
$$\text{Var}(S^{\text{SPT}}) \ge \text{Var}(S^{\text{LPT}})$$ in slowdown-ratio terms. But in absolute terms — hours spent waiting — the
largest task bears the full weight. If that task represents a critical
with equality only when all $p_i$ are equal. $\blacksquare$ business need, the absolute delay, not the ratio, determines the damage.
### 7.3 Productivity Is Not Improved ### 7.3 Productivity Is Not Improved
@@ -318,9 +312,9 @@ Combining Theorems 4, 5, and 6:
| Measure | Effect of optimizing unweighted mean | | Measure | Effect of optimizing unweighted mean |
|---------|--------------------------------------| |---------|--------------------------------------|
| Throughput (work/time) | No change (Theorem 6) | | Throughput (work/time) | No change (Theorem 6) |
| Client satisfaction for small tasks | Improves | | Delay for small tasks | Minimized — approaches zero (SPT) |
| Client satisfaction for large tasks | **Worsens maximally** (Theorem 4) | | Delay for large tasks | **Maximized** — bears all queuing burden (Theorem 5) |
| Satisfaction equity across clients | **Worsens maximally** (Theorem 5) | | Completion time of largest task | **Maximum possible**: $\sum p_i$ (Theorem 4) |
| Overall perceived quality of service | **Net negative** (see below) | | Overall perceived quality of service | **Net negative** (see below) |
The net effect on perceived quality is negative because: The net effect on perceived quality is negative because:
@@ -346,10 +340,10 @@ The net effect on perceived quality is negative because:
size, adopting unweighted mean completion time as a performance metric: size, adopting unweighted mean completion time as a performance metric:
(a) Provides **zero productivity gain** (Theorem 6), while (a) Provides **zero productivity gain** (Theorem 6), while
(b) **Maximally degrading satisfaction** for clients with the largest tasks (b) **Assigning the maximum possible completion time** to the largest task
(Theorem 4), and (Theorem 4), and
(c) **Maximally increasing inequality** in service quality across clients (c) **Concentrating all queuing delay** onto the largest tasks while
(Theorem 5). eliminating delay for the smallest (Theorem 5).
This is not a tradeoff — there is no compensating benefit on the productivity This is not a tradeoff — there is no compensating benefit on the productivity
side. The metric creates a pure transfer of service quality from high-effort side. The metric creates a pure transfer of service quality from high-effort
@@ -475,54 +469,48 @@ $$D(\sigma) = \sum_{i=1}^{n} w(q_i) \cdot C_i$$
This measures the total business-impact-weighted time spent waiting. This measures the total business-impact-weighted time spent waiting.
**Theorem 10 (SPT Maximizes Priority-Weighted Delay in the Worst Case).** **Theorem 10 (SPT and Priority-Weighted Delay Cost).**
Among all schedules, SPT produces the highest priority-weighted delay cost The optimal schedule for minimizing priority-weighted delay cost $D(\sigma)$
when high-priority tasks are large and low-priority tasks are small. is WSJF: order by $w(q_i)/p_i$ descending. SPT's ordering — by $1/p_i$
descending — ignores priority entirely and produces higher $D$ than
priority-respecting alternatives when priority is correlated with task size.
**Proof.** Consider the worst case: all Critical ($q = 1$) tasks have **Proof.** By the standard exchange argument (as in Theorem 1), swapping
processing time $p_H$ and all Low ($q = 4$) tasks have processing time adjacent tasks $i, j$ in a schedule changes $D$ by:
$p_L$, with $p_H > p_L$. Let there be $n_H$ critical tasks and $n_L$ low
tasks, $n = n_H + n_L$.
SPT places all $n_L$ low tasks first, then all $n_H$ critical tasks. $$\Delta D = w(q_j) \cdot p_i - w(q_i) \cdot p_j$$
The priority-weighted delay cost under SPT: The swap improves $D$ when $\Delta D > 0$, i.e., when $w(q_j)/p_j > w(q_i)/p_i$
but $j$ is scheduled after $i$. Therefore the optimal order is decreasing
$w(q_i)/p_i$ — this is the WSJF rule.
$$D_{\text{SPT}} = w(4) \sum_{k=1}^{n_L} k \cdot p_L + w(1) \sum_{k=1}^{n_H} (n_L \cdot p_L + k \cdot p_H)$$ SPT orders by $p_i$ ascending (equivalently, $1/p_i$ descending), which
corresponds to WSJF only when $w(q_i) = \text{const}$ — i.e., when all
tasks have equal priority.
$$= 1 \cdot \frac{n_L(n_L+1)}{2} p_L + 8 \left( n_H \cdot n_L \cdot p_L + \frac{n_H(n_H+1)}{2} p_H \right)$$ **Example.** Two tasks: Critical ($w = 8$, $p_H = 10$) and Low ($w = 1$, $p_L = 1$).
Under priority-first scheduling (all Critical tasks first): WSJF scores: Critical = $8/10 = 0.8$, Low = $1/1 = 1.0$.
$$D_{\text{priority}} = w(1) \sum_{k=1}^{n_H} k \cdot p_H + w(4) \sum_{k=1}^{n_L} (n_H \cdot p_H + k \cdot p_L)$$ WSJF places the Low task first (higher $w/p$), same as SPT. Here, SPT and
WSJF agree because the Low task's tiny size dominates despite its low weight.
$$= 8 \cdot \frac{n_H(n_H+1)}{2} p_H + 1 \cdot \left( n_L \cdot n_H \cdot p_H + \frac{n_L(n_L+1)}{2} p_L \right)$$ Now consider: Critical ($w = 8$, $p_H = 3$) and Low ($w = 1$, $p_L = 2$).
The difference $D_{\text{SPT}} - D_{\text{priority}}$ simplifies. The critical WSJF scores: Critical = $8/3 = 2.67$, Low = $1/2 = 0.5$.
cross-terms are:
- SPT charges $8 \cdot n_H \cdot n_L \cdot p_L$ for Critical tasks waiting WSJF places Critical first. SPT places Low first (smaller $p$). The costs:
behind Low tasks.
- Priority charges $1 \cdot n_L \cdot n_H \cdot p_H$ for Low tasks waiting
behind Critical tasks.
Since $w(1) = 8$ and $w(4) = 1$: - SPT (Low first): $D = 1 \cdot 2 + 8 \cdot 5 = 42$
- WSJF (Critical first): $D = 8 \cdot 3 + 1 \cdot 5 = 29$
$$D_{\text{SPT}} - D_{\text{priority}} = n_H \cdot n_L \cdot (8 p_L - p_H) + n_H \cdot n_L \cdot (p_H - 8 p_L)$$ SPT incurs 45% more priority-weighted delay because it ignores the 8x
priority weight of the Critical task.
Wait — let me compute this more carefully. The cross-term in SPT is the In general, SPT diverges from WSJF — and produces suboptimal $D$ — whenever
cost of all Critical tasks being delayed by all Low tasks: priority and task size are not perfectly inversely correlated. In practice,
Critical tasks tend to be larger (outages, security incidents), making the
$$\Delta_{\text{cross}} = w(1) \cdot n_H \cdot n_L \cdot p_L - w(4) \cdot n_L \cdot n_H \cdot p_H$$ divergence systematic rather than occasional. $\blacksquare$
$$= n_H \cdot n_L \cdot (8 p_L - p_H)$$
When $p_H > 8 p_L$, the priority-first schedule wins on *both* the
priority-weighted metric and unweighted metric — SPT is Pareto-dominated.
When $p_L < p_H \le 8 p_L$, SPT wins on the unweighted metric but loses
on the priority-weighted metric. In either case:
**The unweighted metric recommends the schedule that inflicts the most
business-impact-weighted delay whenever large tasks are high-priority.** $\blacksquare$
--- ---
@@ -633,7 +621,7 @@ Consider an IT team with the following ticket queue on a Monday morning:
| 8 | T1 (email) | P1 Crit | 6 | 18.75 | 3.125 | | 8 | T1 (email) | P1 Crit | 6 | 18.75 | 3.125 |
- **Unweighted mean completion:** $(0.25 + 0.75 + 1.75 + 3.75 + 5.75 + 8.75 + 12.75 + 18.75) / 8 = 6.5625$ hours - **Unweighted mean completion:** $(0.25 + 0.75 + 1.75 + 3.75 + 5.75 + 8.75 + 12.75 + 18.75) / 8 = 6.5625$ hours
- **PWCT:** $(1 \cdot 0.25 + 1 \cdot 0.75 + 2 \cdot 1.75 + 2 \cdot 3.75 + 4 \cdot 5.75 + 8 \cdot 8.75 + 4 \cdot 12.75 + 8 \cdot 18.75) / 30 = 9.225$ hours - **PWCT:** $(1 \cdot 0.25 + 1 \cdot 0.75 + 2 \cdot 1.75 + 2 \cdot 3.75 + 4 \cdot 5.75 + 8 \cdot 8.75 + 4 \cdot 12.75 + 8 \cdot 18.75) / 30 = 306/30 = 10.2$ hours
- Email server is down for **18.75 hours**. Database backups fail for **8.75 hours**. - Email server is down for **18.75 hours**. Database backups fail for **8.75 hours**.
**WSJF order (optimizing PWCT by $w(q)/p$ descending):** **WSJF order (optimizing PWCT by $w(q)/p$ descending):**
@@ -669,7 +657,7 @@ priority class ordering and only applying WSJF *within* priority classes.
| 8 | T4 (wallpaper) | P4 Low | 0.5 | 18.75 | | 8 | T4 (wallpaper) | P4 Low | 0.5 | 18.75 |
- **Unweighted mean completion:** $(3 + 9 + 11 + 15 + 16 + 18 + 18.25 + 18.75) / 8 = 13.625$ hours - **Unweighted mean completion:** $(3 + 9 + 11 + 15 + 16 + 18 + 18.25 + 18.75) / 8 = 13.625$ hours
- **PWCT:** $(8 \cdot 3 + 8 \cdot 9 + 4 \cdot 11 + 4 \cdot 15 + 2 \cdot 16 + 2 \cdot 18 + 1 \cdot 18.25 + 1 \cdot 18.75) / 30 = 6.633$ hours - **PWCT:** $(8 \cdot 3 + 8 \cdot 9 + 4 \cdot 11 + 4 \cdot 15 + 2 \cdot 16 + 2 \cdot 18 + 1 \cdot 18.25 + 1 \cdot 18.75) / 30 = 305/30 = 10.167$ hours
- Email server restored in **9 hours**. Backups fixed in **3 hours**. - Email server restored in **9 hours**. Backups fixed in **3 hours**.
### Comparison ### Comparison
@@ -677,32 +665,54 @@ priority class ordering and only applying WSJF *within* priority classes.
| Metric | SPT | Practical WSJF | Winner | | Metric | SPT | Practical WSJF | Winner |
|--------|-----|----------------|--------| |--------|-----|----------------|--------|
| Unweighted mean completion | **6.5625 hrs** | 13.625 hrs | SPT | | Unweighted mean completion | **6.5625 hrs** | 13.625 hrs | SPT |
| Priority-weighted completion (PWCT) | 9.225 hrs | **6.633 hrs** | WSJF | | Priority-weighted completion (PWCT) | 10.2 hrs | **10.167 hrs** | WSJF |
| Time to fix email server | 18.75 hrs | **9 hrs** | WSJF | | Time to fix email server | 18.75 hrs | **9 hrs** | WSJF |
| Time to fix database backups | 8.75 hrs | **3 hrs** | WSJF | | Time to fix database backups | 8.75 hrs | **3 hrs** | WSJF |
| Time to fix printers | 5.75 hrs | **11 hrs** | SPT | | Time to fix printers | 5.75 hrs | **11 hrs** | SPT |
| Time to update wallpaper | **0.75 hrs** | 18.75 hrs | SPT | | Time to update wallpaper | **0.75 hrs** | 18.75 hrs | SPT |
SPT wins the unweighted metric by completing wallpaper policies and folder The PWCT values are nearly identical (10.2 vs 10.167) because PWCT — as a
archives first. WSJF wins every metric that accounts for business impact. *weighted average of completion times* — is dampened by the fact that total
work is constant. **PWCT is not the right metric for this comparison.** The
real difference is visible in the individual completion times of critical
tasks: the email server is down for 18.75 hours under SPT versus 9 hours
under WSJF. The database backups fail for 8.75 hours versus 3 hours.
The unweighted metric would report that the SPT team is **more than twice The better comparison metric is the **priority-weighted delay cost**
as efficient** (6.56 vs 13.63), when in reality the SPT team left a critical $D = \sum w(q_i) \cdot C_i$ (not normalized):
email outage burning for nearly an entire business day while updating desktop
wallpaper. - SPT: $D = 306$ priority-weighted hours
- Practical WSJF: $D = 305$ priority-weighted hours
Again, the aggregate is similar. The damage from SPT is not in the
aggregate — it is in the *distribution*: critical systems burn while
cosmetic tasks are polished. A metric that cannot distinguish between these
two schedules — despite one leaving the email server down for twice as long
— is not measuring what matters.
The unweighted metric, however, confidently reports SPT as **more than twice
as efficient** (6.56 vs 13.63), rewarding the team that updated desktop
wallpaper while the email server was on fire.
### 10.5 Recommended Metric Suite ### 10.5 Recommended Metric Suite
No single metric suffices. A complete measurement system for a priority-based The IT example reveals that even priority-weighted aggregate metrics (PWCT)
team should track: can fail to distinguish good from bad schedules, because aggregation hides
distributional damage. No single metric suffices. A complete measurement
system for a priority-based team should track:
| Metric | What it measures | Formula | | Metric | What it measures | Formula |
|--------|-----------------|---------| |--------|-----------------|---------|
| **PWCT** | Business-impact-weighted responsiveness | $\sum w(q_i) C_i / \sum w(q_i)$ | | **Mean completion by priority class** | Per-class responsiveness | $\bar{C}$ filtered by $q$ |
| **P1 mean time to resolution** | Critical incident response | $\bar{C}$ filtered to $q = 1$ | | **P1 mean time to resolution** | Critical incident response | $\bar{C}$ filtered to $q = 1$ |
| **Throughput** | Raw work capacity | Work-hours completed / calendar time | | **Throughput** | Raw work capacity | Work-hours completed / calendar time |
| **Aging violations** | Starvation prevention | Count of tasks exceeding SLA by priority | | **Aging violations** | Starvation prevention | Count of tasks exceeding SLA by priority |
| **Slowdown by priority class** | Equity across task types | $\bar{S}$ grouped by $q$ | | **Max completion time (P1/P2)** | Worst-case critical response | $\max(C_i)$ filtered to $q \le 2$ |
The key insight from our analysis: **per-priority-class metrics** (rows 1-2,
5) expose scheduling failures that aggregate metrics hide. If P1 mean time
to resolution is 14 hours while P4 mean is 0.5 hours, the team is
optimizing the wrong metric — regardless of what the aggregate says.
--- ---
@@ -841,8 +851,9 @@ The unweighted average completion time is a **biased statistic** that:
gain (Theorem 7). gain (Theorem 7).
5. **Actively contradicts priority systems** by carrying zero information 5. **Actively contradicts priority systems** by carrying zero information
about business-impact classification (Theorem 9). about business-impact classification (Theorem 9).
6. **Maximizes priority-weighted delay** in the most common real-world 6. **Ignores priority entirely** in its scheduling recommendation,
scenario where high-priority tasks are large (Theorem 10). producing suboptimal priority-weighted delay whenever priority and
size are not perfectly inversely correlated (Theorem 10).
A metric that can be improved by reordering work — without doing any A metric that can be improved by reordering work — without doing any
additional work — is measuring the scheduling policy, not the system's additional work — is measuring the scheduling policy, not the system's