How the sandbox calculates your results

This page explains every number the sandbox shows you. Each result in the editor can be opened with Explain, which shows the formula below with your own values substituted. You should be able to check any of them with a calculator.

The engine is analytic: it uses closed-form formulas and a simple queueing approximation. It is not a packet-level network simulator, and it does not model radio energy, packet loss, retransmissions or contention between devices sharing a wireless channel. All hardware, link and price figures are teaching approximations chosen to make the trade-offs visible. They are close enough to reason with, not to buy equipment with.

Engine version: 1.0.0

1. How data flows

Each source (for example 24 ward cameras) produces events at a fixed rate. Every event travels from its source to each sink that needs it, along exactly one route through your nodes and links.

• λ (lambda) is an arrival rate in events per second. For a source, λ = count × eventRateHz. A link or node carries the sum of the λ of every source whose route passes through it.
• A node or source with R replicas stands for R identical copies (for example one device per camera). Each copy handles λ ÷ R.
• The payload on a hop depends on which stages have already run upstream: the raw event size before the first stage, then the output size of the latest stage that has run.
• Stages must run in model order along every route (preprocess, then inference, then postprocess), and every route to a sink must pass through every stage.
• A stage marked as needing all sources (the S5 flood forecast) runs once per reporting interval on a single node. After it, data flows at the per-source rate (one forecast per interval), not count × rate.

Data form and privacy

Data on a hop is in one of three forms:

Every node has a location: on-device (compute inside the sensor unit), on-premises (a separate box on site) or off-premises (the cloud, a hosted dashboard). When a hop goes from an on-device or on-premises node to an off-premises node, the data on it leaves the premises. The privacy result is the most revealing form that leaves, with its data class (public, operational, personal, sensitive personal). Results derived from personal data are still personal data: a fall alert names a patient.

Separately, any network hop carrying personal or sensitive-personal data without TLS is a violation, wherever it is.

2. Messages on a link

Every event (or batch of events) becomes a message.

Encoding multiplier

Per-message overhead (connection reused)

• TLS adds 22 bytes per message (TLS 1.3 record overhead).
• Turning connection reuse off opens a new connection for every message: it adds 4,000 bytes (TCP + TLS handshake with certificate chain; 200 bytes without TLS) and 2 round trips of latency (1 without TLS). A round trip is 2 × the one-way latency. This is why MQTT's persistent connection matters for small, frequent messages.
• The on-board bus (a camera wired to its own processor) has no protocol, encoding or TLS overhead.

Message size

messageBytes = eventsPerMessage × payload × encodingMultiplier + protocolOverhead + tlsRecord (+ handshakeBytes)

Streaming, micro-batching and batching

• Stream: one message per event, so eventsPerMessage = 1.
• Micro-batch and batch with window W seconds and S sender replicas: each sender collects events for W seconds and sends them together.

eventsPerMessage = max(1, λ × W ÷ S)

The protocol overhead is paid once per batch, which is how batching saves bandwidth. The price is waiting: an event waits on average W ÷ 2 for its batch to leave, and W at worst.

3. Latency

Transmission (putting the bits on the wire):

tx = messageBytes × 8 ÷ bandwidth

Propagation is the medium's one-way latency, plus handshake round trips if connections are not reused.

Link utilisation ρ is the fraction of time a link is busy. Bandwidth is per sender replica: each of 24 cameras has its own 80 Mbps Wi-Fi in this model (shared-channel contention is not modelled).

ρ = (messages/s per sender × messageBytes × 8) ÷ bandwidth

At ρ ≥ 1 the link cannot keep up and the design is infeasible. Between 0.8 and 1 you get a warning, because queues grow quickly near saturation.

Processing. Each stage needs gopsPerEvent billion operations per event. The node's effective throughput depends on whether the accelerator is used:

effectiveGops = accelPeakTops × 1,000 × accelUtilisation        if the accelerator is used
effectiveGops = cpuGops × cpuUtilisation × (0.5 if fp32 else 1)  otherwise
Ts = gopsPerEvent ÷ effectiveGops

Default utilisation is 0.3 for accelerators and 0.6 for CPUs: real models rarely get close to a vendor's headline TOPS figure. The accelerator is used only if the stage's format has a precision the accelerator supports and can be loaded by a runtime the accelerator uses. Otherwise the stage falls back to the CPU and you get a warning.

Node utilisation:

ρ = Σ over stages on the node (λ per replica × Ts)

ρ ≥ 1 means the node is overloaded.

Queueing (M/M/1 approximation). When work arrives at random, a busy server builds a queue. The engine uses the textbook M/M/1 result for the mean waiting time:

Wq = Ts × ρ ÷ (1 − ρ)

For a link, Ts is the mean transmission time per message. This approximation assumes random (Poisson) arrivals and random service times. Real camera frames arrive at regular intervals, which queue less, so treat Wq as a cautious estimate.

Serverless cold starts. A managed serverless endpoint scales out on demand, so it has no queue and cannot be overloaded, but some requests land on a cold instance. The average adds coldStartMs × pCold; the worst case adds the full coldStartMs.

End-to-end latency to a sink:

average = Σ hops (tx + propagation + W ÷ 2 + Wq) + Σ nodes (processing + Wq) + coldStart × pCold
worst   = Σ hops (tx + propagation + W + Wq)     + Σ nodes (processing + Wq) + coldStart

The worst case is named "worst case (excluding queueing variance)": it takes the full batching window and full cold start, but includes queueing only at its mean, because the engine does not model how long the queue tail can get. A sink fed by several sources reports its slowest route.

4. Bandwidth and cost

Monthly traffic on a link (a 30-day month is 2,592,000 seconds):

GB/month = bytes per second (all senders) × 2,592,000 ÷ 10⁹

The total shown in the summary bar adds up every network link. On-board buses are excluded because they never touch a network.

Monthly cost

A serverless endpoint is invoked once per incoming message, so batching reduces invocations. Fixed link charges are per sender: 24 devices on 4G need 24 SIM plans. Scenario budgets apply to operating plus amortised capital cost. Cloud egress fees are not modelled.

5. Energy

For edge devices (per unit, per day):

Wh/day = (activeW × ρ + idleW × (1 − ρ)) × 24  (+ local training time × (activeW − idleW))

For a battery-powered source, the battery must also run the sensors and any on-device compute fed directly from it:

battery days = batteryWh ÷ (baselinePowerW × 24 + on-device Wh/day)

Radio energy is not modelled. A 4G modem uses far more energy than a LoRaWAN radio, and sending less data saves battery. Treat this as a discussion point in your justification.

6. Model formats and accuracy

• The format must be loadable by a runtime on the node.
• Memory per stage = paramsMillions × bytes per parameter × 1.5 MB (4 for fp32, 2 for fp16, 1 for int8; the 1.5 approximates activations). All stages on a node must fit in its memory.
• Pipeline accuracy = the inference stage's base accuracy + the quantisation change for its precision (fp32 0, fp16 −0.1, int8 −1.0 percentage points unless the scenario says otherwise).

7. Training (scenario S6)

• Centralised: every source sends trainingBytesPerSourcePerDay of raw data each day to one node. Traffic = sources × bytes per day × 30 ÷ 10⁹ GB/month, charged on every link along the way. If that node is off-premises, raw data leaves the premises.
• Federated: the nodes running the inference stage train locally and exchange a model update with an aggregator each round (upload plus download). Traffic = replicas × 2 × modelUpdateMB × roundsPerWeek × 30/7 ÷ 1,000 GB/month. Raw data never moves.
• Training transfers are assumed to run off-peak, so they count towards bandwidth and cost but not link utilisation.

Model updates can still leak information about the training data (for example through membership-inference attacks). The engine does not model this; it is a discussion point for your justification.

8. Deployment model badge

9. Design rule check

With any error, metrics show as not computable until it is fixed. Violations do not block the metrics but count against the design.

Worked example A: streaming edge pipeline (S1, ward fall detection)

Design. 24 cameras send every frame over Wi-Fi (MQTT, binary encoding, TLS, connection reused, streaming) to one industrial gateway (Intel N100 class). The gateway runs all three stages as onnx-int8 on its integrated GPU through OpenVINO. It sends each alert over Ethernet (MQTT, JSON, TLS) to the nurse-station alarm, and over 4G (MQTT, JSON, TLS, streaming) to the management dashboard.

Arrival rate. λ = 24 cameras × 5 frames/s = 120 events/s.

Hop 1: Wi-Fi, cameras → gateway

Gateway: three stages on the iGPU

onnx-int8 is int8 (in the iGPU's precisions) and loads in OpenVINO (the iGPU's runtime), so the accelerator is used.

The gateway is busy 41% of the time, so a frame waits about 2.4 ms on average behind others. That is already most of the processing time: queueing matters long before a node is "full".

Hop 2: Ethernet, gateway → alarm

Latency to the alarm

There is no batching and no cold start, so the worst case (excluding queueing variance) is also 15.72 ms, far inside the 1,000 ms limit. The same route through 4G to the dashboard averages 50.31 ms.

Dashboard link, cost and other results

Every constraint passes. The 4G link streams 120 tiny messages per second to a dashboard that only needs daily statistics. Try batching it hourly and watch the traffic fall.

Worked example B: micro-batched hybrid pipeline (S4, adaptive traffic junction)

Design. Each of the 12 cameras has a Raspberry Pi 5 with a Hailo-8L NPU inside its housing (on-device, 12 replicas), joined by the on-board bus. Vehicle detection runs on the NPU as hef-int8. Detections go over 5G (MQTT, protobuf, TLS) in 200 ms micro-batches to one cloud GPU instance, which runs the per-lane counting as tensorrt-fp16. The cloud streams counts back over 5G to the 4 signal controllers, and sends one-minute batches over the cloud network (HTTP, JSON, TLS) to the city dashboard.

Inference runs on site and a later stage runs in the cloud, so the badge is Hybrid. λ = 12 × 10 = 120 frames/s.

Hop 1: on-board bus, camera → its Pi

Pi + Hailo-8L: detection

Hop 2: 5G uplink, 200 ms micro-batches

Streaming would send 10 messages of 222 bytes per second per camera (2,220 bytes/s). Batching pairs sends 5 messages of 382 bytes (1,910 bytes/s): 14% less traffic, paid for with 100 ms of average waiting.

Cloud GPU: counting

Hop 3: 5G downlink, cloud → controllers

Latency to the signal controller

The average meets the 200 ms limit. The batching window is 79% of the average latency, which is the first thing to tune.

Dashboard batch, cost and other results

All four constraints pass, but the cloud GPU is 83% of the bill for a job that uses 0.0002% of it. Is the cloud stage worth its cost and its dependence on 5G? That is the kind of trade-off your justification should argue.