Limits and Interpretation

Implemented boundary

The current implementation:

• evaluates explicit work and pipeline files offline;
• uses deterministic component and queue arithmetic;
• prints QEMU TCG and icount arguments;
• maps a supplied instruction count to guest model time;
• fits and validates component corrections from supplied observations.

It does not:

• capture QEMU instruction counts automatically;
• synchronize QEMU, Renode, CnuasSwitch, CnuasLink, or facility clocks live;
• model a CPU microarchitecture or claim cycle accuracy;
• infer device timing from host wall-clock execution;
• provide a physical calibration dataset;
• model priority, pre-emption, back-pressure protocols, or failures;
• perform electrical transient, CFD, cooling, or grid stability simulation.

Reading an analytic result

An analytic result should be written as:

Under profile cnuas-analytic:0.1.0, this explicit pipeline produced the following deterministic virtual-time estimate.

It should not be written as:

Cnuas predicts that the physical product has this latency.

Reading a calibrated result

A calibrated result is valid only for its:

• named hardware and firmware;
• configuration and software versions;
• measured workload range;
• queue, flow, rank, and concurrency conditions;
• held-out error report.

Calibration does not make the model universal. Extrapolation beyond the measured range must be identified and separately checked.

Common errors

Error	Why it is wrong
Dividing host time by one ratio	Host overhead changes by component and workload
Calling icount cycle accurate	Instructions are not physical microarchitecture cycles
Using fit RMSE as validation	The same data selected the coefficients
Changing evidence by hand	No target measurements or held-out score support it
Omitting packet or tensor shape	Performance regimes change with shape
Combining independent resources under one key	Creates false contention
Splitting one shared resource into many keys	Removes real contention
Adding lanes without hardware basis	Creates unsupported parallel capacity

Choosing a more detailed model

Use a specialist simulator when the research question depends on:

• cache coherence or out-of-order CPU execution;
• detailed GPU pipelines, warps, caches, or memory controllers;
• packet protocol state, congestion control, or topology dynamics;
• electrical protection or power-quality transients;
• thermal airflow or coolant fluid dynamics.

Such a simulator can later provide traces or costs to a Cnuas component stage. The common pipeline remains useful for composing that specialist result with the rest of the rack.

Planned extensions

Extension	Purpose
Runtime trace adapters	Import actual emulator work counts
Clock federation	Coordinate live QEMU, Renode, and daemon model time
Versioned hardware datasets	Publish target-specific profiles and held-out errors
Residual analysis tools	Identify missing resources and non-linear regimes
Confidence intervals	Represent repeated-measurement variability
Priority and back-pressure	Model richer shared-resource scheduling