an uncalibrated power model is an estimate, not ModelBased #220
Loading…
Reference in a new issue
No description provided.
Delete branch "fix/uncalibrated-model-is-estimate"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Why
The JCP metering ladder (
jcp/SPEC.md§5.1) defines two of its rungs as:ModelBased.Estimator.Several crates multiplied wall time by a default power that was never calibrated on the host and graded the result
ModelBased:By the spec's own ladder these are estimates. Grading them
ModelBasedclaimed better provenance than the figures had.What
Every figure computed from a constant nobody calibrated on the host is now
Estimator. Where a host-calibrated path exists it staysModelBased:Meter::UncalibratedTimePowerandRung::UncalibratedTimePower, gradedEstimator.detect()falls back to it, and so do the counter, IOReport and per-process spans.Meter::time_power(mw)staysModelBasedand is documented as requiring a power the host measured. jcp-conformance C9 checks both grades.grade_attemptfallback are nowEstimator. proof-schema gainsEnergy::estimator.Estimatorunless the newMicroVmConfig.calibratedis set.Estimator.Estimatorunless the newWasmConfig.fuel_cost_calibratedis set.Estimator.boot_microvmexample's fallback isEstimator.Estimated, as the GPU seeds already were.Estimator.spec/receipts.md, and theProvenancedocs and READMEs.API: the new names are additive. The two new public config fields,
MicroVmConfig.calibratedandWasmConfig.fuel_cost_calibrated, would break struct-literal construction outside their crates; there is none in the repo.Evidence
ModelBasedproducer in non-test code was classified as calibrated (kept), uncalibrated (regraded), apportionment of a real reading (kept), or pass-through (kept).Not covered
Four sites are over-graded the same way, but regrading them would change signed vectors. They are left for the owner to decide:
jouleclaw-jcr1v1.1 vector 12, and the frozenvectors.jsonentry 6;ModelBasedfigures;joulecontract-receipt's demotion of an unattestedMeteredclaim toModelBased.🤖 Generated with Claude Code
SPEC §5.1 grades rung 5 as wall time × a HOST-CALIBRATED active power (ModelBased) and rung 6 as an estimate. jcp-energy's ladder fell to Meter::TimePower at DEFAULT_ACTIVE_MILLIWATTS (15 W, an assumed figure no host measured) and every counter rung's span degraded to the same 15 W figure, all graded ModelBased: better provenance than how the figure was obtained. The power is the whole of that model, so a default power is a constant scaled by time, an estimate. - Meter::UncalibratedTimePower { milliwatts } and Rung::UncalibratedTimePower (Estimator), built by Meter::uncalibrated_time_power; detect() falls to it, so Detection.selected, rung() and provenance() all say estimate. - Meter::TimePower / Meter::time_power stay ModelBased, documented as a power calibrated on this host. - counter_span / ioreport_span / process_span degrade to the new uncalibrated_span (Estimator) instead of Energy::modeled. - Tests that pinned the over-claim now pin Estimator: the RAPL/NVML/ per-process/IOReport fallback-span tests, the declined-IOReport meter test, and the detect_with selection tests. New tests: a host-calibrated power stays ModelBased while the default is Estimator, detect() falls to the estimate, and the fallback span helper. - jcp-conformance C9 now checks both grades. - SPEC §5 / §5.1 rungs 5-6, jcp-schema's Provenance docs and the README say a default or assumed power is rung 6. No vector changes (jcp gen-vectors output is byte-identical; no jcp vector carries ModelBased). Co-Authored-By: Claude Opus 5.5 <[email protected]>