Worked Examples¶

CnuasNIC packet and bandwidth bottlenecks¶

The reference CnuasNIC profile has:

100 ns fixed analytic latency;
100 Gbit/s analytic bandwidth;
148.8095 Mpacket/s analytic packet rate;
overlapping resources.

For four packets and 4 KiB:

[ t_B=\frac{4096\times8}{100}=327.68\ \mathrm{ns}, ]

[ t_P=\frac{4\times1000}{148.8095}=26.88\ \mathrm{ns}. ]

Bandwidth is the larger dynamic term:

[ t=100+\max(327.68,26.88)=427.68\ \mathrm{ns}. ]

Run:

cnuas-timing predict profiles/cnuas-analytic-v0.json cnuasnic \
  --bytes 4096 --packets 4

For minimum packets, the packet-rate term can become the bottleneck. Sweeping packet size shows where the limiting resource changes.

ORV3 RS-485 frame transfer¶

The ORV3 segment runs at 19,200 baud. With one start bit, eight data bits, and one stop bit, payload throughput is:

[ 19200\times\frac{8}{10}=15360\ \mathrm{bit/s}. ]

An eight-byte frame therefore needs:

[ \frac{8\times8}{15360}=4.167\ \mathrm{ms} ]

of wire time:

cnuas-timing predict profiles/cnuas-analytic-v0.json bmc-rs485 --bytes 8

This does not include transceiver turnaround, firmware processing, inter-frame silence, retries, or polling contention. Add those as fixed cost or separate stages after measurement.

CnuasGPU compute and memory¶

Model compute and memory as separate stages when each has its own queue:

{
  "stages": [
    {
      "name": "load-operands",
      "component": "cnuasgpu-memory",
      "work": {"bytes": 4194304}
    },
    {
      "name": "matrix-operation",
      "component": "cnuasgpu-compute",
      "work": {"operations": 2147483648}
    },
    {
      "name": "store-result",
      "component": "cnuasgpu-memory",
      "work": {"bytes": 1048576}
    }
  ]
}

The reference compute and memory rates are illustrative. Replace them with a named target profile before making a hardware prediction.

Queueing at a shared switch¶

Use the same cnuasswitch component key in every fabric-hop stage that shares one switch service resource. Jobs then contend for the same lane availability.

Use different keys, such as switch-a and switch-b, for independent physical resources. Copy the same rates into both profile entries when their characteristics are equal.

Two-lane versus one-lane service¶

For a 100 ns component and two jobs arriving at time zero:

Lanes	Completion times	Interpretation
1	100 ns, 200 ns	Second job waits
2	100 ns, 100 ns	Jobs run in parallel

Changing lanes is a modelling decision, not a free speed multiplier. It must represent independently serviceable work on the selected component.

End-to-end RDMA to GPU example¶

The shipped pipeline contains:

guest submit instructions;
CnuasNIC transmit;
one CnuasSwitch fabric hop;
PCIe transfer;
CnuasGPU compute.

cnuas-timing simulate profiles/cnuas-analytic-v0.json \
  examples/rdma-gpu-pipeline.json --jobs 100 --trace > rdma-gpu.json

This demonstrates composition. It is not an assertion that every RDMA to GPU operation has exactly these stages. Build a pipeline from the actual software and device path under study.

Reproducible experiment bundle¶

Keep these files together:

experiment/
  profile.json
  pipeline.json
  command.txt
  result.json
  training-observations.json
  calibration.json
  held-out-observations.json
  validation.json
  target-manifest.txt

Record the Cnuas commit and timing package version in target-manifest.txt.