Architecture & Measurement-Design Analysis

Shockwave: Fair and Efficient Cluster Scheduling for Dynamic Adaptation in Machine Learning

Source: Zheng, P.; Pan, R.; Khan, T.; Venkataraman, S.; Akella, A. arXiv:2210.00093v1 [cs.DC], 30 Sep 2022 (NSDI'23). Code: https://github.com/uw-mad-dash/shockwave Authors: University of Wisconsin-Madison + The University of Texas at Austin. Reader: pdftotext direct extraction (gemini-reader script pinned to a retired model) Analyst: Vishwakarma Date: 2026-09-01

Table of Contents

1. System Architecture (the scheduler itself)
2. System-Under-Test Architecture (cluster testbed + simulator)
3. Design-Space Diagram (axes swept, axes held fixed)
4. Algorithm & Control Flow Diagrams (prediction, solve, lease, dispatch)
5. Quantitative Results — Empirical Findings by Regime
6. Configuration-Regime Trade-off Tables
7. Bottlenecks & Insights Surfaced by the Measurements
8. Limitations of the Methodology
9. Analogy

1. System Architecture (the scheduler itself)

Shockwave is a centralized, round-based GPU cluster scheduler with a finite-horizon planning window. Its distinguishing choice is that the scheduling decision is a function not of each job's current throughput but of a forecast trajectory of its future throughput; everything else exists to make that forecast cheap enough to compute every round. Section 6 (Figure 6) gives six numbered interactions:

+-------------------------------------------------------------------+
|                    SHOCKWAVE SCHEDULER                            |
|                                                                   |
|  (1) new job arrives                                              |
|        |                                                          |
|        v                                                          |
|  +--------------------------+      +--------------------------+   |
|  | Bayesian Predictor       |----->| Active Job Pool          |   |
|  | Dirichlet PRIOR          |      | (all schedulable jobs)   |   |
|  |  Dir(N/K, ..., N/K)      |      +--------------------------+   |
|  +-----------+--------------+                                     |
|              ^  (2) epoch done / batch-size scaling reported      |
|  +-----------+--------------+                                     |
|  | (3) Restatement Posterior|                                     |
|  |     Update Rule          |                                     |
|  |  Dir(m1,..,mk,Sk,..,Sk)  |                                     |
|  +-----+--------------+-----+                                     |
|        |              |                                           |
|  forecast future   predict (remaining) run time                   |
|  batch-size sched     |                                           |
|        |              v                                           |
|        |   +-------------------------------------------------+    |
|        |   | (4) EFFICIENCY est: makespan lower bound H(Y)   |    |
|        |   |     (Coffman et al. bin-packing bound)          |    |
|        |   +-------------------------------------------------+    |
|        |   | (5) FAIRNESS est:                               |    |
|        |   |     rho_hat(j) = (Lj+Wj+R^*Navg)/(P^*Navg)      |    |
|        |   +-----------------------+-------------------------+    |
|        v                           v                              |
|  +--------------------------------------------------------+       |
|  | (6) SCHEDULE SOLVER  (Gurobi MILP, 15 s timeout)        |      |
|  |     generalized Nash Social Welfare over Time           |      |
|  |     max_X  sum_j rho_hat(j)^k * log( sum_t UTIL_j )     |      |
|  |                / (N*M)   -   lambda * H(X) / Z0         |      |
|  +---------------------------+----------------------------+       |
|         N x T binary matrix X (T = 20 rounds default)             |
|  +---------------------------v----------------------------+       |
|  | Lease Manager + Model Dispatcher                        |      |
|  |  create / extend / lapse lease; pre-dispatch model+data |      |
|  +---------------------------+----------------------------+       |
|  +---------------------------v----------------------------+       |
|  | Placement Engine (Gavel): tight packing + machine       |      |
|  |  affinity to previously-used nodes                      |      |
|  +---------------------------+----------------------------+       |
+------------------------------|------------------------------------+
                               v
        +----------------------------------------------+
        | GPU WORKERS (1 worker == 1 GPU device)       |
        |  launch / suspend / resume, ckpt via NFS     |
        +----------------------------------------------+
^ Fig 1: Shockwave design, reproducing the six numbered interactions
  of Figure 6 of the paper. The two estimators (4)(5) are the bridge
  between a *finite* planning window and the paper's *long-term*
  fairness and efficiency guarantees.

The critical decision is the position of the two estimators. The market theory is defined over an infinite horizon but the solver plans only T = 20 two-minute rounds, so the estimators are what let a 40-minute plan be scored by effects resolving hours later. Fairness enters as a weight (the Fisher-market budget), efficiency as a regularizer — an asymmetry that is itself a design statement.

The same system as an abstraction stack:

+---------------------------------------------------+
| User training job: monitors gradients, decides    |  <- owns the
|  batch-size scaling (Accordion / GNS / expert /   |     adaptation
|  static)                                          |     policy
+---------------------------------------------------+
| Shockwave scaling API  (gRPC scaling requests)    |  <- job tells
+---------------------------------------------------+     scheduler
| Shockwave policy layer                            |  <- the paper's
|   Bayesian predictor | estimators | NSW solver    |     contribution
+---------------------------------------------------+
| Gavel cluster manager: meta-data collector,       |
|   schedule translator, lease mgr, placement       |
+---------------------------------------------------+
| Gurobi (MILP solve)     | Linux NFS (checkpoints) |
+---------------------------------------------------+
| GPU workers: 1 process bound to 1 GPU device      |
+---------------------------------------------------+
^ Fig 2: Software stack. Shockwave is implemented in Python atop
  Gavel; the batch-size scaling policy deliberately stays ABOVE the
  API line, in the user's program.

The layer boundary at the scaling API is the paper's central commitment (Section 2.3): Shockwave observes and forecasts dynamic adaptation but never performs it, unlike Pollux, which owns both batch size and worker count. Shockwave thus inherits the user's accuracy unchanged and pays for it in lost worker elasticity.

2. System-Under-Test Architecture (cluster testbed + simulator)

Two evaluation vehicles run the same scheduling code base and solver engine: a 32-GPU physical TACC cluster and a discrete-event simulator for the 64/128/256-GPU studies.

+--------- Physical testbed: 8 nodes x 4 GPUs = 32 GPUs (TACC) ------+
|    Node 0              Node 1            ...        Node 7         |
|  +------------+     +------------+                +------------+   |
|  | 2x Intel   |     | 2x Intel   |                | 2x Intel   |   |
|  | Xeon       |     | Xeon       |                | Xeon       |   |
|  | E5-2620 v4 |     | E5-2620 v4 |                | E5-2620 v4 |   |
|  | "Broadwell"|     | "Broadwell"|                | "Broadwell"|   |
|  | 128 GB DDR4|     | 128 GB DDR4|                | 128 GB DDR4|   |
|  +-----+------+     +-----+------+                +-----+------+   |
|  | 4x NVIDIA  |     | 4x NVIDIA  |                | 4x NVIDIA  |   |
|  | Quadro     |     | Quadro     |                | Quadro     |   |
|  | RTX 5000   |     | RTX 5000   |                | RTX 5000   |   |
|  | (16 GB)    |     | (16 GB)    |                | (16 GB)    |   |
|  +-----+------+     +-----+------+                +-----+------+   |
|        |                  |                             |         |
|        +==================+=============================+         |
|              100 GB/s inter-node                                   |
|              200 GB/s inter-switch     (as reported in Sec. 8.1)   |
|   Storage: Linux NFS (model checkpoints), overhead < 3%            |
+--------------------------------------------------------------------+
^ Fig 3: Physical system under test. 1 worker = 1 GPU; job sizes in
  the trace are 1, 2, 4, or 8 workers, so an 8-worker job spans two
  nodes and crosses the inter-node link.

Bandwidths are stated in the paper as "200 GB/s inter-switch and 100 GB/s inter-node". No interconnect microbenchmark is presented and no result is attributed to communication bandwidth — decisions are made at round granularity (120 s), far above any collective's timescale. The harness pairs the cluster with a simulator whose fidelity is itself measured:

+-------------------------------------------------------------------+
|                  EVALUATION HARNESS                               |
|                                                                   |
|  +--------------------------------------------------------+       |
|  | Workload generator: Gavel's [33] + Pollux trace (App. J) |      |
|  |   5 model/dataset pairs | Poisson arrivals lambda .1-.2  |      |
|  |   job len 0.2-5 h | workers {1,2,4,8}                    |      |
|  |   size mix S .72 / M .20 / L .05 / XL .03                |      |
|  |   mode per job: Static | Accordion | GNS                 |      |
|  +---------------------------+----------------------------+       |
|  +---------------------------v----------------------------+       |
|  |     SAME SCHEDULER CODE BASE + SAME SOLVER ENGINE       |      |
|  +----------------+-------------------+-------------------+       |
|                   |                   |                           |
|        +----------v-------+   +-------v------------------+        |
|        | Physical cluster |   | Discrete-event simulator |        |
|        | 32 GPUs (TACC)   |   | 64 / 128 / 256 GPUs      |        |
|        | 120 jobs         |   | 220 / 460 / 900+ jobs    |        |
|        | (+14 GPUs, App I)|   | contention factor ~3     |        |
|        +----------+-------+   +-------+------------------+        |
|                   +--------+----------+                           |
|  +---------------------------v----------------------------+       |
|  | Metric extractor                                        |      |
|  |   efficiency : makespan, cluster utilization            |      |
|  |   fairness   : worst-case FTF rho, unfair job fraction  |      |
|  |   responsive : average JCT                              |      |
|  +---------------------------+----------------------------+       |
|  +---------------------------v----------------------------+       |
|  | Fidelity check (Table 3): sim vs physical difference    |      |
|  |   makespan 4.97% | avg JCT 4.62% | unfair frac 3.83%    |      |
|  +--------------------------------------------------------+       |
+-------------------------------------------------------------------+
^ Fig 4: Evaluation harness. The simulator is validated against the
  physical cluster BEFORE being used for the 64-256 GPU claims; the
  measured gap is ~5% on all three metric families.

Publishing the simulator/physical residual (Table 3) is what makes the 256-GPU / 900-job claims credible. Workload table, from Table 2:

Job-size mix, verbatim from Section 8.1:

The distribution is heavily skewed toward short jobs: makespan is set by the 3% Extra-Large tail while average JCT is set by the 72% Small head, so a scheduler can move one without the other. Shockwave's headline claim is exactly that it moves makespan without degrading average JCT.

3. Design-Space Diagram (axes swept, axes held fixed)

+-------------------------------------------------------------------+
|                        DESIGN SPACE                               |
|                                                                   |
|  Axis 1: BASELINE SCHEDULER (7 levels + Shockwave)                |
|    OSSP (MILP makespan) | MST (max-sum-throughput)                |
|    Gavel (max-min fair) | AlloX (bipartite match)                 |
|    Themis (partial allocation) | Gandiva-Fair (stride/lottery)    |
|    Pollux (goodput, p-norm; Sec 8.7 only)                         |
|                                                                   |
|  Axis 2: CLUSTER SCALE (4 levels)                                 |
|    [32 GPU phys / 120 jobs] <- ground truth; [64 GPU sim / 220+]; |
|    [128 GPU sim / 460+]; [256 GPU sim / 900+]                     |
|    (+ 14 GPU physical for the contention sweep, Appendix I)       |
|                                                                   |
|  Axis 3: STATIC / DYNAMIC JOB MIX (4 levels, Fig. 10)             |
|    (S,D) = (1.0,0.0) (0.6,0.4) (0.3,0.7) (0.0,1.0)                |
|                                                                   |
|  Axis 4: CLUSTER CONTENTION FACTOR (Appendix I): [3] [2] [1.5]    |
|                                                                   |
|  Axis 5: PREDICTION NOISE (Fig. 13)                               |
|    [oracle] [0%] [20%] [40%] [60%] [100%]                         |
|                                                                   |
|  Axis 6: SOLVER TIMEOUT (Fig. 12)                                 |
|    [1 s ............ 15 s]  x  {500, 1000, 2000 active jobs}      |
|                                                                   |
|  Axis 7: TRACE SOURCE                                             |
|    [Gavel synthetic generator]  [Pollux production trace]         |
|                                                                   |
|  Axis 8: POSTERIOR UPDATE RULE (Fig. 5)                           |
|    [restatement rule]  [standard Bayesian]  [greedy/most-recent]  |
|                                                                   |
|  ---------------------------------------------------------------  |
|  HELD FIXED (no sweep):                                           |
|    - Round duration:        120 s                                 |
|    - Planning window T:     20 rounds (~40 min)                   |
|    - FTF weight exponent k: 5      (robust over [1, 10])          |
|    - Regularizer lambda:    1e-3   (robust over [1e-4, 1e-2])     |
|    - Solver timeout:        15 s   (except Axis 6)                |
|    - Dynamic-adaptation mode: reactive (lazy mode not evaluated)  |
|    - Workers per job: FIXED for job lifetime (prototype choice)   |
|    - Batch-size scaling policy: Accordion or GNS only             |
|    - Utility form: linear / Leontief (Cobb-Douglas not evaluated) |
|    - Budgets: EQUAL across jobs (weighted priorities not swept)   |
|    - Placement engine and hardware: Gavel's / RTX 5000, unchanged |
+-------------------------------------------------------------------+
^ Fig 5: Eight swept axes and the fixed frame around them. The most
  consequential entry in the fixed list is "workers per job fixed":
  it makes the Pollux comparison (Sec. 8.7) asymmetric by
  construction, and the paper says so explicitly.

Two absences shape how the results read. The lazy rescheduling mode is implemented but never measured, so the cost of deferring a resolve is unquantified. And budgets are always equal: the market supports weighted proportional fairness, but nothing exercises it.

4. Algorithm & Control Flow Diagrams

4.1 Regimes and trajectories — the prediction object

Before any control flow, the object being predicted must be defined. The paper's abstraction (Section 5) is:

   A REGIME  R = (c, f):  c = job configuration (e.g. batch size)
                          f = duration as a FRACTION of total epochs
   A TRAJECTORY = an ordered sequence of regimes

   Worked example from the paper (100-epoch job):

   epoch:  1 ............ 20 | 21 ................ 80 | 81 ..... 100
          +-----------------+------------------------+-------------+
          | c1 = BS_32      | c2 = BS_64             | c3 = BS_32  |
          | f1 = 0.2        | f2 = 0.6               | f3 = 0.2    |
          +-----------------+------------------------+-------------+
             ^ regime 1          ^ regime 2               ^ regime 3

   Because scaling RULES are deterministic, c_k is KNOWN and only
   f_k is random:
      Accordion : alternates between exactly two configs c1 <-> c2
                  (up when gradient change is slow, down when fast)
      GNS       : monotonically scales UP to a preset limit,
                  never scales down; batch size doubles when
                  gradient noise crosses a relative threshold
+-------------------------------------------------------------------+
^ Fig 6: The regime abstraction. Fixing the configuration sequence
  and randomizing only the durations is what collapses an
  intractable forecasting problem into a Dirichlet over K numbers.

This is the paper's key modelling economy: "what batch size will this job use and when" is hopeless, while "how long will each of the K known phases last" is a K-simplex problem with a conjugate prior.

4.2 The restatement posterior update rule

  START: job J arrives, user declares at most K regimes
     |
     v
 (1) [PRIOR]  Dir( N/K, N/K, ..., N/K )      (N = total epochs)
     |          "assume all K regimes split epochs evenly"
     |
     v
 (2) job trains; epoch completes  OR  batch-size scaling fires
     |
     +-----> is regime k COMPLETE?
     |            |               |
     |           NO              YES
     |            |               |
     |            |               v
     |            |    (3) [RESTATEMENT UPDATE]
     |            |        observed epochs m1..mk are FIXED
     |            |        remaining epochs split evenly:
     |            |          S_k = (N - sum_{k} m_k) / (K - k)
     |            |        posterior <- Dir(m1,..,mk, S_k,..,S_k)
     |            |               |
     |            <---------------+
     |            |
     v            v
 (4) take the MEAN of the posterior as the single trajectory
     (one trajectory per job -- avoids combinatorial explosion
      of the cluster-wide trajectory space)
     |
     v
 (5) sum regime expected durations -> total run time
     total run time - elapsed T_j  -> REMAINING run time
     |
     v
 (6) hand to (a) solver, as the utility/throughput schedule
              (b) FTF estimator, as the remaining-time input
     |
     v
  loop back to (2)
^ Fig 7: The restatement rule. Standard Bayesian updating assumes
  epoch samples are drawn i.i.d.; the paper points out that epochs of
  regime k cannot appear until regime k-1 finishes, so the temporal
  dependence breaks the standard rule. The restatement rule handles
  this by only ever updating parameters for COMPLETED regimes.

Step (4) keeps this tractable at cluster scale: each job contributes exactly one trajectory, the posterior mean, because the joint space across all jobs is combinatorially large.

4.3 One scheduling round, end to end

  Round T boundary
     |
     v
 (1) Collect events since last solve: job arrivals | completions |
     epoch completions | batch-size scaling notifications (gRPC)
     |
     v
 (2) Per active job: restatement posterior update (Fig 7)
       -> forecast batch-size schedule + (remaining) run time
     |
     v
 (3) FAIRNESS estimator, per job j:
       rho_hat(j) = (L_j + W_j + R_hat(j)*Navg(j)) / (P_hat(j)*Navg(j))
       L_j = attained service time ; W_j = waiting time
       R_hat / P_hat = predicted remaining / total isolated run time
       Navg(j) = contention factor over j's queued+running window
     |
     v
 (4) EFFICIENCY estimator (makespan lower bound, Coffman et al.):
       H(Y) = max{ sum_j R(Y_j) / M ,  max_j R(Y_j) }
              ^ "spread evenly over M GPUs"  ^ "longest job alone"
     |
     v
 (5) SOLVE (Gurobi MILP, 15 s timeout, separate thread):
       max_X  sum_j rho_hat(j)^k * log(sum_t UTIL_j(X[j,t])) / (N*M)
              -  lambda * H(X) / Z0
       decomposed at REGIME level when adaptation is predicted
       inside the window; output is the N x T matrix X
     |
     v
 (6) LEASE MANAGER translates X[.,T+1] into actions:
       idle now, scheduled next    -> create lease + dispatch
       running now, scheduled next -> extend lease (same workers)
       running now, not next       -> lease lapses, worker stops
     |
     v
 (7) PLACEMENT ENGINE maps job -> GPUs: tight packing
     (anti-fragmentation) + previous-machine affinity
     |
     v
  Round T+1 begins
^ Fig 8: One round. Note that (5) runs asynchronously in a separate
  thread and is invoked mid-round, so its cost is hidden as long as
  it stays under half a round.

The re-solve trigger is not purely periodic: the program is recomputed when planned rounds elapse, when jobs arrive or complete, and — in reactive mode — immediately on a scaling event.

4.4 Job lease state machine

                 scheduled for T+1 (not running in T)
    [QUEUED] --------------------------------------> [DISPATCHED]
        ^                                                  |
        |                                          round boundary
        |             lease NOT renewed                    v
   [SUSPENDED] <---------------------------------------[RUNNING]
        |                                              |     ^
        +---- rescheduled (prefers previous machines) -+     |
                                        lease renewed -------+
                                        (stays on SAME workers)
                          all epochs done
                    [RUNNING] -------------> [COMPLETE]
^ Fig 9: Lease lifecycle. The solver penalizes scattering a job across
  non-contiguous rounds and the placement engine prefers
  previously-allocated workers -- two independent mechanisms aimed at
  restart cost. Checkpointing runs over Linux NFS at under 3%.

4.5 Agnostic vs reactive vs proactive — the motivating control flow

Figures 2 and 4 contrast three scheduler postures. As decision flow:

   Job reports / cluster observes throughput change
                    |
      +-------------+--------------+-------------------+
      |             |                                  |
   AGNOSTIC      REACTIVE                          PROACTIVE
      |             |                                  |
      v             v                                  v
  ignore it;   update throughput NOW;         forecast the WHOLE
  keep using   recompute finish estimate;     trajectory before it
  initial      re-prioritize in future        happens; plan the
  throughput   rounds                         window accordingly
      |             |                                  |
      v             v                                  v
  +--------+   +----------------------+      +---------------------+
  | 30%    |   | 22.3% worse makespan |      | reference point     |
  | worse  |   | 28% worse cluster    |      | (best makespan and  |
  |makespan|   |    utilization       |      |  utilization)       |
  +--------+   +----------------------+      +---------------------+
  | FTF    |   | misses the fairness  |      | meets the deadline  |
  | rho =  |   | deadline by 2.07x    |      |                     |
  | 3.07   |   |                      |      |                     |
  +--------+   +----------------------+      +---------------------+
   makespan/utilization row: Fig. 4 MILP example
   FTF row: Fig. 2 trace job (batch size doubles 3x, 32 -> 256,
   speeding training up to 1.7x)
^ Fig 10: Why reacting is not enough. Reactive scheduling has already
  under-prioritized the job during its slow early phase, and there is
  no way to retroactively compensate.

The argument is structural, not empirical: FTF is defined against t_egalitarian = t_exclusive * N, so a scheduler estimating t_exclusive from current throughput overestimates it for any job that will later speed up.

5. Quantitative Results — Empirical Findings by Regime

5.1 Physical cluster, 32 GPUs, 120 jobs (Figure 7)

Relative-to-Shockwave bar annotations of Figure 7; lower is better.

[derived inference] The bar-to-scheduler assignment is reconstructed from legend order; each column's aggregate reproduces a prose-stated figure exactly — makespan mean over {Themis, Gavel, AlloX} = 1.29 ("1.3x less"), MST makespan 1.37 ("37% improvement"), worst-FTF mean = 2.00 ("2x on average"), unfair-fraction mean = 2.73 ("2.7x").

Absolute values stated in prose:

[derived inference] Dividing the OSSP and MST absolute unfair fractions by their relative bars (70.8/8.50 and 25/3.00) both give about 8.3%, implying Shockwave's own unfair fraction here is roughly 8.3%; the paper does not state this directly.

5.2 Simulation at scale, 64 / 128 / 256 GPUs (Figure 9)

Reported as ranges across the three cluster sizes.

The 5-9% makespan deficit against OSSP is the price of the fairness constraint: an unconstrained MILP makespan minimizer still wins on makespan, but schedules 70.8% of jobs unfairly on the physical trace.

5.3 Static vs dynamic job mix (Figure 10)

Results across the sweep:

This sweep decomposes the paper's win: the all-static column isolates the social-welfare formulation (18% makespan), and the rise to 1.3x as D grows is attributable to prediction — roughly two-thirds formulation, one-third forecasting. [derived inference]

5.4 Prediction accuracy (Figure 5)

The greedy baseline is what every reactive scheduler uses, so Figure 5 is both a component ablation and a justification for the premise.

5.5 Resilience to prediction error (Figure 13)

Relative to the oracle-prediction run; noise is +/- p% injected into the interpolated job run time, all jobs dynamic.

The degradation profile is asymmetric. The paper's reading: fairness is protected by the structure of Nash social welfare — the log-product objective heavily penalizes skewed progress and keeps the scheduler conservative even under biased estimates — while efficiency, which depends on identifying long-running jobs to prioritize, degrades directly with run-time error. Even the 30%-degraded efficiency stays on par with Themis, Gavel and AlloX.

5.6 Solver overhead (Figure 12, Section 8.9)

Solver quality improves with diminishing returns from 1 s to 15 s. At 2000 jobs the bound gap exceeds Gurobi's recommendation by 4.4x; the paper reports "limited impact" without quantifying it.

5.7 Shockwave vs Pollux (Section 8.7, Figure 11)

Both systems run the same Pollux trace; the Pollux simulator runs first to harvest the observed batch-size schedule, which is fed to the Shockwave simulator so job processing times match.

The paper frames this as not like-for-like: Shockwave's constrained prototype competes with one hand tied, and Pollux's JCT advantage is bought with an accuracy loss Shockwave refuses to incur.

5.8 Contention and trace sensitivity (Appendices I and J)

Contention sweep, 14-GPU physical cluster:

5.9 Motivating measurements (Sections 2.1 - 2.3)

Themis static-filter study, Table 1 (3 jobs; serial 1-GPU iteration times 12, 8, 6; requested GPUs per iteration 3, 2, 2; 4-GPU cluster):

Figure 1 reports FTF-rho of (0.78, 0.83, 1.1) for jobs (A, B, C) under the fixed f = 2/3 filter. Pollux auto-scaling accuracy study (Figure 3, ResNet-18 / CIFAR-10, 2 GPUs, initial batch size 32):

The ResNet-50 / ImageNet expert heuristic is different again — scale by 10x at epochs 30, 60 and 80 — evidence that no single scaling rule transfers across models. A companion NeuMF / ML-1M study (Appendix A.2) shows Pollux jumping from 256 to 32768 at epoch 1 with degraded hit-rate and NDCG, while an expert schedule waiting until epoch 3 matches vanilla accuracy.

6. Configuration-Regime Trade-off Tables

6.1 Scheduler posture toward dynamic adaptation

Shockwave chooses proactive because reactive scheduling cannot retroactively repay a job it under-prioritized during that job's slow early phase: the deadline has already been inflated by the stale throughput estimate.

6.2 Where fairness and efficiency enter the objective

Shockwave prefers the asymmetric form because the FTF weight is the only place the market's budget concept can enter; a job at risk of violating fairness must outbid an efficient schedule, not merely offset it additively.

6.3 Who owns the batch size

Shockwave chooses user-owned adaptation because its own measurements show no scaling rule transfers across models (ResNet-18, ResNet-50 and NeuMF each need a different expert schedule), so a scheduler imposing one rule costs accuracy on some jobs.

6.4 Posterior update rule

Shockwave chooses the restatement rule because epochs of regime k cannot be observed until regime k-1 completes, violating the i.i.d. sampling assumption standard Bayesian updating requires.

6.5 Planning horizon length

Shockwave chooses a finite window because infinite-horizon planning is prohibitive and unpredictable while single-round planning is the instantaneous-fairness trap Gavel and DRF fall into; the estimators recover long-horizon signal inside a short-horizon program.

6.6 Baseline scheduler positioning

7. Bottlenecks & Insights Surfaced by the Measurements

7.1 The fairness deadline is the real object being corrupted

Every failure mode the paper demonstrates traces to a mis-estimate of t_exclusive, not to a bad allocation given a correct estimate. A job that will later double its batch size has a smaller true t_exclusive than current throughput implies; agnostic and reactive schedulers hand it a longer deadline than it deserves, conclude it is fairly treated, and deprioritize it. Under dynamic adaptation, fairness metrics are themselves forecasts.

7.2 Static filters are a knob that cannot be tuned once and left

Table 1 shows four filter settings producing four distinct (fairness, JCT, makespan) outcomes on a three-job example, none dominating. The paper's objection is that tuning is "challenging without any insight into the resulting performance outcomes, and it is more difficult when the workload varies" — the standard argument for deriving a threshold rather than setting it. Shockwave's rho_hat(j)^k weight is the adaptive filter, computed not configured.

7.3 Efficiency degrades under prediction error; fairness does not

Figure 13's asymmetry exposes a structural property: the log-product form of Nash social welfare punishes skew in progress, and skew is observable from realized allocations regardless of forecast quality. Efficiency instead depends on ranking jobs by remaining length so long jobs can be packed — a ranking noise destroys directly. The fairness guarantee is robust to the predictor; the efficiency gain is not.

7.4 The win decomposes into formulation and forecasting

The all-static column of Figure 10 is a clean ablation: with zero dynamic jobs the predictor contributes nothing, yet Shockwave still delivers an 18% makespan improvement and an unfair fraction under 5% purely from maximizing social welfare over a planning window; as the dynamic fraction rises to 1.0 the advantage grows to 1.3x. The market formulation is the larger contribution.

7.5 Two workload properties multiply the reported gain

Appendix I shows the makespan advantage collapsing from 35% at contention 3 to 8% at contention 1.5, all policies' worst-case FTF converging to 1.0: a scheduler can only express a preference where resources are scarce. Appendix J shows the same win dropping from 30-35% on the synthetic trace to 20% on the Pollux trace, the cause being 2x greater job-duration diversity in the synthetic trace — opportunistic prioritization of long jobs has nothing to work with when all jobs are similar. Both contention level and duration spread are gain multipliers, so the headline configuration sits deliberately where policy matters most.

7.6 The solver is deliberately kept off the critical path

Round 120 s, solver timeout 15 s, solve invoked mid-round in a separate thread: "the solver overhead is hidden when it is less than half-round duration." This converts a latency problem into a quality problem — the cost of scaling is a widening bound gap (0.03% / 0.11% / 0.44% at 500 / 1000 / 2000 jobs), not a stalled cluster — and is why 900-job scalability comes without a stall.

7.7 The tractability collapse is where theory meets practice

The volatile Fisher market is defined over a distribution of future trajectories; the implementation carries exactly one per job, the posterior mean, explicitly to avoid combinatorial explosion. Everything downstream — MILP, estimators, regime-level utility decomposition — rests on that approximation, and Figure 13 is its sensitivity study. Restart churn gets a similar double treatment: solver contiguity preference plus placement affinity, neither ablated.

8. Limitations of the Methodology

The last row matters most from a distributed-systems angle. Shockwave's utility is epoch progress per round, measured empirically; whether a job is compute-bound or limited by inter-node bandwidth is represented nowhere in the market, so the scheduler cannot prefer a placement that reduces communication and delegates that entirely to Gavel's packing heuristic. Batch-size scaling is precisely the adaptation that shifts a job's compute-to-communication balance, so the dimension Shockwave forecasts most carefully is the one whose communication consequences it models least.

9. Analogy

Shockwave is a hospital operating-theatre scheduler that plans around how quickly each patient is expected to recover, rather than how sick they look this morning.

The theatres are the GPUs and the two-minute rounds are the fixed blocks the day is divided into. Every patient (job) holds the same voucher (equal budget) entitling them to a fair share of theatre time — the Fisher market. A conventional scheduler allocates today's blocks from each patient's current condition; that is instantaneous fair share, and it is what Gavel and DRF do. But some patients are on a therapy that will make them dramatically faster to treat in three weeks (batch-size scaling), and a scheduler judging them by today's condition writes down a discharge date far later than the true one, which makes the patient look fairly treated while being pushed to the back of every queue. That inflated date is t_egalitarian, and corrupting it is exactly how reactive scheduling breaks fairness.

Shockwave's answer maps in three parts. The Bayesian predictor is the prognosis model: it never guesses the whole clinical course, only how long each known phase of a known therapy protocol will last — Accordion and GNS are the protocols, and only phase durations are uncertain. The restatement rule is the discipline of revising the chart only for phases that have actually finished, assuming the rest will evenly divide the time left, because you cannot observe week four before week three happens. The generalized Nash social welfare objective is the admissions committee: patients drifting toward missing their discharge date get a louder vote (the rho^k weight, their budget), while a mild penalty nudges the committee to keep the ward emptying quickly (the makespan regularizer). The 20-round window with its two estimators is the committee planning only the next forty minutes in detail while scoring each plan by its effect on discharge dates hours away.

The measured behaviour follows from the analogy. On a ward of fixed courses (all-static) the committee still beats the alternatives by 18% on ward-clearing time, purely from planning ahead rather than re-deciding every block; with every patient on adaptive therapy the advantage grows to 1.3x; and on a nearly empty ward (contention 1.5) it falls to 8%, because there is nothing to arbitrate. When prognoses are made deliberately unreliable the promised discharge dates are still broadly honoured — the log-product objective punishes anyone falling badly behind regardless of forecasts — while ward throughput suffers, because packing long cases requires knowing which cases are long.