70 lines
3.9 KiB
Markdown
70 lines
3.9 KiB
Markdown
# Scheduler Efficiency Audit: 2026-09-08
|
|
|
|
## Measured Baseline
|
|
|
|
The fixed sample is cycles 4915-4934. See `efficiency-audit-baseline.md`
|
|
and `.json` for per-cycle commands, event gaps and phase measurements.
|
|
|
|
| Measurement | Seconds | Interpretation |
|
|
|---|---:|---|
|
|
| Elapsed wall time | 1914.684 | First request start through last completion |
|
|
| Within model cycles | 815.747 | Includes process startup and cancellation |
|
|
| First activity wait | 811.684 | No command, edit or message arrived |
|
|
| Between cycles | 1098.937 | Includes retry, preparation and restart time |
|
|
| Preparation steps | 5.973 | Not additive to between-cycle wall time |
|
|
| Commands executed | 0 | No native work ran in this sample |
|
|
|
|
The old phase-only average omitted inter-cycle waiting. Shorter cancelled
|
|
requests alone did not demonstrate higher business throughput.
|
|
|
|
## Implemented Changes
|
|
|
|
1. Separate the first-response budget from post-activity idle detection.
|
|
Consecutive silent attempts allow 30, 60, 120, then at most 180 seconds.
|
|
Real stream errors retain their own error budget. Active commands are protected.
|
|
2. Persist increasing retry delays: 20, 40, 60, 120, 240, 480, at most 600 seconds.
|
|
A real model response clears the failure streak. Restarting does not clear it.
|
|
3. Record actual retry sleep under `waitingTiming.scheduler/provider-backoff`.
|
|
The status viewer and analyzer include it once and keep it out of command time.
|
|
4. Report runtime budgets and the loaded scheduler source SHA-256. Clear stale
|
|
per-turn timing and failure labels, and freeze elapsed time at completion.
|
|
5. Allocate restart cycle IDs above log, status, timing and progress IDs, including
|
|
deterministic pipeline cycles which have no model log.
|
|
6. Share request failure accounting between periodic optimization and business
|
|
turns. Maintenance failures extend the same persisted backoff; a real response
|
|
clears it. Maintenance health does not create business progress records.
|
|
|
|
Existing source, artifacts, build caches, verified business evidence and unresolved
|
|
records are preserved. No business is marked complete by these scheduler changes.
|
|
The existing Draft evidence-reuse benchmark already measured 3.020565 seconds
|
|
fresh versus 0.210055 seconds reused (93.05% reduction for that case only), using
|
|
the same evidence path. That historical result was reused, not rerun or claimed
|
|
as a new improvement in this audit.
|
|
|
|
## Verification
|
|
|
|
- `test_scheduler_efficiency.py`: 73 passed.
|
|
- `test_scheduler_performance.py`: 24 passed.
|
|
- `test_scheduler_step_timing.py`: 7 passed.
|
|
- `test_unattended_scheduler.py`: 22 passed.
|
|
- `test_scheduler_maintenance.py`: 12 passed. Combined run: 138 passed.
|
|
- A controlled delayed subprocess survives the shorter post-activity idle limit
|
|
and completes within its first-response budget. A silent subprocess still times out.
|
|
- Retry timing and the status viewer agree on 92 seconds for a fixture with
|
|
30 seconds request time, 2 seconds preparation and 60 seconds retry sleep.
|
|
- Restart-ID regression retains logless pipeline records.
|
|
- Live v16 cycle 4941 used 120 seconds and recorded retry sleep; cycle 4942 used
|
|
180 seconds. These are confirmed loaded runtime budgets, not source-only settings.
|
|
- Final reload: PID 1230029 reported v16 with the loaded source SHA-256 matching
|
|
the file on disk. Retry count 6 survived restart. Cycle 4945 recorded 180.054
|
|
seconds request time and 239.929 seconds retry sleep as separate measurements.
|
|
|
|
## Remaining Limitation
|
|
|
|
A read-only Codex request to return READY, without tools or repository access,
|
|
received no response before the external 180-second bound (exit 124). Later
|
|
scheduled requests also reached the 120/180-second first-response limits.
|
|
This establishes observed request unavailability, not its underlying provider cause.
|
|
The scheduling fixes reduce repeated requests and preserve slow-start opportunities;
|
|
they do not establish restored service or increased business throughput.
|