- event 17
Effective sandbox resources are smaller than the container flags suggest: the Docker Desktop VM exposes 8 CPUs and 3.83 GiB of memory (docker info), so the 6g memory flag is not binding. Pre-declared plan, before any data is downloaded or any result seen: run the authors unmodified reproduce_experiments_ucr.py with its defaults (10 runs, 10,000 kernels) on each of the 85 bake-off datasets, one dataset per process, single-threaded (numba is serial; BLAS threads pinned to 1), several datasets concurrently. If a dataset runs out of memory, rerun only that dataset with a driver that calls the same authors functions and the same classifier but transforms and scores the test set in chunks after training; this changes memory use only, not the computation, and will be recorded as a deviation.
- event 39
Launch history: launch 1 serialized all jobs behind StarLightCurves (no backfill); a stop attempt then killed only itself, so launch 2 ran alongside launch 1 for under a minute with both writing to runs/job00. Both launches were stopped before any dataset finished and their files are kept in runs_aborted_launch1_and_2/ for the record. Launch 3 starts clean; only its outputs are used.
- event 42
During launch 3, jobs containing StarLightCurves, FordA, FordB and Wafer ended with SIGKILL (returncode -9), consistent with the kernel OOM killer: the memory estimate did not account for the old and new transform arrays coexisting during reassignment in the authors loop, and other containers share the 3.83 GiB VM. Per the plan declared at event 17, the full pass continues unchanged; afterwards every dataset that was killed is rerun with the memory-only chunked driver, and partner datasets in killed jobs (whose results were never written) are rerun with the unmodified script.
- event 49
Scheduling change mid-pass (no change to what is computed). Diagnosis: the VM had only about 2 GB free for this sandbox (other containers and the VM itself hold about 1.4 GB; swap was full), and the container cgroup recorded 12 OOM kills. The first scheduler is stopped; its three running jobs (job11, job16, job19) are left to finish. run_all2.py now starts a job only when live MemAvailable leaves room. Datasets never attempted, and the partner datasets in killed jobs, run with the authors unmodified script; the 12 datasets whose jobs were killed run with analysis/rocket_lowmem.py, verified at events 45 and 47 to give bit-identical predictions, regularization and coefficients to the authors in-memory path.
- event 54
Scheduler v2 also saw OOM kills (FordB and NonInvasiveFetalECGThorax1 under the low-memory driver, DiatomSizeReduction/Phoneme unmodified) and had no retry logic. Replaced by run_all3.py: the work list is derived from result files on disk, killed jobs are retried (up to 3 attempts per dataset) with concurrency reduced after each kill, and jobs already running are left alone. ElectricDevices is routed straight to the low-memory driver without the unmodified attempt planned at event 17: the authors in-memory path needs roughly 5 GB and the VM has about 2 GB free, after 17 OOM kills on much smaller jobs. Number of runs (10) and kernels (10,000) are unchanged.
- event 60
Event 57 exited 143 because its pkill pattern also matched the command line of the shell running it, so it stopped the first run_all3 instance and itself before moving the directory or relaunching. No job processes were affected (verified by process listing). Events 58-59 completed the step.
- event 72
Flaw found in the equivalence check (events 45, 47, 62, 68): its authors-path subprocess imported rocket_lowmem for data loading, and importing that module applies all of its scikit-learn patches. Those checks therefore compared the patched path with itself and do not establish equivalence. This surfaced at events 70-71, when a broken patch crashed the supposed authors path. All low-memory results are treated as unverified until every driver version used in production (written at events 43, 46, 61, 67) is re-checked against a genuinely unpatched authors path.
- event 94
Claim electricdevices-train-minutes is left untested. ElectricDevices could only run with the low-memory driver (the in-memory path needs about 5 GB; the VM had about 2 GB free), which keeps the 8,926 x 20,000 training transform in a disk-backed array; under memory pressure this measured 27.0 minutes of training per run (event 86). That figure reflects the workaround, not the method, so it is not a valid test of the 6-minute single-core claim. Its accuracy (0.729724 vs 0.7305 in Table 1) is included in the accuracy claims.
- event 95
Paper version: claims were checked against Table 1 of arXiv v1 (the PDF fetched for this attempt). The repository results file (results/results_ucr.csv, updated in July 2020 for the journal version) differs from arXiv v1 for some datasets (e.g. ACSF1 0.886 in the repository vs 0.8780 in arXiv Table 2), so the two published versions are not numerically identical.
- event 102
Provenance corrections after finish. (1) The code snapshot counted the untracked code/__pycache__/ directory as a modification; git status shows no tracked changes and no diff was captured, so the authors code ran unmodified. (2) The report sandbox-time figure counts only commands run directly through the shell tool (about 24 minutes). The batch runs were detached processes: about 13 hours of wall-clock time from the first launch to the end of the ElectricDevices run, and about 18.5 core-hours of measured compute for the 85 datasets (10 runs x 111.18 minutes), plus OOM-killed attempts.