Cnuas Calibrated Virtual-time and Performance Model

Status: deterministic analytic model available, physical calibration datasets planned · Package: timing/ · Profile: timing/profiles/cnuas-analytic-v0.json

Purpose and claim boundary

The Cnuas timing model adds a repeatable notion of time to the functional emulators without treating host wall-clock speed as simulated hardware speed. The current release evaluates explicit pipelines offline. It does not yet synchronize the live clocks of QEMU, Renode, and the host daemons. It supports three distinct evidence classes:

Evidence	Meaning
Functional	An interface, state transition, or output is correct
Analytic virtual time	A versioned profile produces a deterministic estimate
Calibrated prediction	A profile was fitted to a named physical target and scored on held-out measurements

The profile shipped with Cnuas is analytic. It is useful for experiments, queueing studies, deterministic replay, and designing calibration campaigns. It is not a benchmark and does not predict any physical device.

Architecture

flowchart LR Work[Workload description] --> Stages[Component stages] Profiles[Versioned timing profiles] --> Scheduler Stages --> Scheduler[Integer-picosecond event scheduler] ICount[QEMU icount virtual clock] --> Scheduler Scheduler --> Trace[Deterministic event trace] Trace --> Estimate[Latency and throughput estimate] Measurements[Physical measurements] --> Fit[Target-specific calibration] Estimate --> Fit Fit --> Calibrated[Calibrated component profile] Holdout[Held-out measurements] --> Error[MAE, RMSE, MAPE, maximum error] Calibrated --> Error

Work describes instructions, cycles, bytes, packets, and operations without binding them to one component. A ComponentProfile supplies the corresponding rates, fixed latency, parallel lane count, and whether resources overlap or run serially. A pipeline associates work with named components. The scheduler uses integer picoseconds and stable lane selection, so the same inputs produce the same event trace.

For an overlapping component, service time is:

[ t_{\mathrm{analytic}}=t_{\mathrm{fixed}}+ \max\left( \frac{I}{R_I}, \frac{C}{f}, \frac{8B}{R_B}, \frac{P}{R_P}, \frac{O}{R_O} \right). ]

Serial components use the sum of active resource terms instead of the maximum. A calibrated component applies:

[ t_{\mathrm{target}}=\max(0,\alpha t_{\mathrm{analytic}}+\beta), ]

where (\alpha) and (\beta) are fitted only from measurements of a named target. Validation reports mean absolute error, root mean squared error, mean absolute percentage error, and maximum absolute error on observations excluded from fitting.

Component coverage

The reference profile includes:

Domain	Model input
Guest CPU	QEMU icount instructions and shift
PCIe	Payload bytes against a configured generation and width
CnuasNIC	Packet and byte service
CnuasSwitch	Fabric-hop packet and byte service with queue contention
CnuasGPU	Tile cycles, operations, memory bytes, and parallel lanes
CnuasLink	Frame bytes and per-hop fixed cost
CnuasBMC	Modbus RTU frame bytes at the ORV3 19,200-baud bus rate
Facility	Telemetry and control-loop cadence for power roll-up

Every supplied latency or rate that is not fixed by a protocol is labelled as an assumption in the profile. Component authors can replace one profile entry without changing the scheduler or pipeline.

Runtime trace ingestion and live clock federation are planned. Until then, instruction, packet, byte, cycle, and operation counts are explicit experiment inputs rather than values captured automatically from running emulators.

QEMU virtual time

cnuas-timing qemu-args --shift N produces a deterministic TCG configuration:

-accel tcg,thread=single -icount shift=N,align=off,sleep=off -rtc clock=vm

At shift (N), each executed guest instruction advances virtual time by (2^N) nanoseconds. This creates a deterministic CPU clock. It does not create device timing. PCIe, DMA, queues, memory, interrupts, fabrics, and accelerators remain explicit component stages.

QEMU documents icount as instruction counting, not cycle-accurate emulation. Cnuas uses the same boundary.

The standard Cnuas VM path continues to use KVM. Instruction-counted runs are a separate experiment mode because QEMU icount requires TCG.

Calibration protocol

A publishable physical-target result should:

1. Name hardware and firmware revisions, clocks, links, software versions, and thermal or power policy.
2. Record packet or tensor shape, queue and flow counts, batch size, and all other workload conditions.
3. Split observations into fitting and held-out validation sets.
4. Store the profile, observations, calibration coefficients, random seeds if used by the workload, and event trace.
5. Report held-out errors and the range over which the calibration was tested.

A statement such as "10 Cnuas PPS equals 1 hardware PPS" is therefore valid only for the exact target and workload used to derive it. It is not a general conversion.

Usage

cd timing
PYTHONPATH=src python3 -m cnuas_timing.cli predict \
  profiles/cnuas-analytic-v0.json cnuasnic --bytes 4096 --packets 4

PYTHONPATH=src python3 -m cnuas_timing.cli simulate \
  profiles/cnuas-analytic-v0.json examples/rdma-gpu-pipeline.json --jobs 100

PYTHONPATH=src python3 -m pytest tests

See timing/README.md for calibration and held-out validation commands.