OMT stores every object as encrypted, erasure-coded shares spread across subscriber nodes, then serves viewers from the nearest node by racing the siblings for the first k shares. Set the dials to your access network, your fleet and your policy. The simulator estimates a single-viewer ceiling, aggregate delivery under equal demand in all groups, and the first limiting resource.
MODEL ONLY · lab not connected100 nodes · 4 service groups
What the dials mean
Access network
The tiers you sell and the shared upstream pool on a service group. Upstream is the scarce resource: every share a node supplies leaves through its modem.
Erasure policy
How many data shares (k) each chunk is split into and how many parity shares protect it. A viewer pulls one share from each of k suppliers at once, so raising k can raise speed until another limit is reached.
Fleet
How many nodes you have, how they are grouped, which hardware serves viewers, and how many sit behind Wi-Fi.
Demand
Concurrent viewers per group, and whether shares stay inside the viewer's group or are spread across groups.
A paced playback test, separate from the capacity model below. The website reads published snapshots; it does not launch tests or increase lab viewer count.
Checking playback feed…
Video window
Waiting for published lab media.
Playback starts only when selected. This 1080p preview streams from the website. It has not been delivered through the lab nodes. The measurements alongside it belong to the earlier synthetic segment tests, not this clip.
Initial playback profile
20 nodes · 2 simulated viewers · 4 Mbps each 2-second segments · 5-minute session Real-time pacing · cache hits and sibling bootstrap No node failures injected
Budget: 8 Mbps total media payload, about 300 MB over five minutes; 150 segments per viewer. Protocol, coding and sibling overhead are additional.
Planned stages: 2 → 5 → 10 → 20 viewers. Each increase follows a passing run beside ORC. Failure and reassignment tests come later.
Profile in published snapshot
Awaiting lab snapshot.
Completed paced-segment tests · September 20, 2026
20-node lab; five minutes per stage; 4 Mbps per viewer; 2-second, 1 MB deterministic data segments; 5+2 coding. These measure the OMT delivery path, not HLS decoding or rendered-video quality.
Viewers
Byte-exact segments
Aggregate Mbps
First segment p50 ms
Segment p50 ms
Segment p95 ms
Drops
Deadline misses
2
300/300
8.0
70.38
32.66
45.2
0
0
5
750/750
20.0
72.53
36.86
47.42
0
0
10
1500/1500
40.0
97.75
50.62
64.06
0
0
20
3000/3000
80.0
143.79
71.48
96.77
0
0
All-stage totals: 5,550/5,550 byte-exact segments; 5.55 GB delivered; 0 origin bytes; 5.859 GB supplied by siblings. Mesh cache-hit ratio: 100% by bytes (delivered minus origin bytes, divided by delivered bytes). This is not a pure local-cache hit rate: all requests used siblings, including requests assisted by one local share.
Accounting observation: closing batches were durable but required node reconnection before all 5,550 requests reconciled. No node-failure injection was performed. The lab was cleaned up and stopped after the run.
The cards below show the 20-viewer stage. Cache-hit and sibling counters were reported across all stages only, so their per-stage cards remain unmeasured. Startup means first segment fully received; simulated rebuffer means a segment missed its two-second deadline. Actual video-player startup and stalls have not been measured.
Startup timeNot measured
Segment latency · p50Not measured
Segment latency · p95Not measured
Sustained deliveryNot measured
Cache-hit ratioNot measured
Sibling trafficNot measured
Dropped segmentsNot measured
Rebuffer eventsNot measured
Rebuffer durationNot measured
How to read these measurements
Startup is the time to first playback. Segment latency is request-to-complete-body time. Sustained delivery is received media bits per session second per viewer. Cache hits require server classification; sibling traffic requires transfer counters. Dropped segments miss their playback deadline. Rebuffer events count stalls after startup, excluding user pauses and seeks; they are not dropped video frames. Uninstrumented values stay “Not measured”.
Updates are requested every 30 seconds while this page is visible. Running snapshots older than 90 seconds are marked stale. Completed runs remain recorded results, never live measurements.
Simulator
Move the dials your network gives you.
Model curves update instantly. Lab results remain separate from the model; calibration and provenance determine comparability.
Single-viewer ceiling—MB/s · Mb/s
Aggregate per busy service group—MB/s with N viewers
Time to first byte—ms · model
What limits it—
Storage overhead—losses tolerated
Fleet usable capacity—per service group
Upstream per delivered byte—bytes sent per byte viewed
Aggregate delivery versus data shares k
shares in the viewer's groupshares spread across groupslimitslab overlays pending
Show as a table
Service groups at this demand
serving edgewired supplierWi-Fi supplierdown
Bars show each group's shared upstream pool at the current demand. Click a node to mark an illustrative outage. These markers do not change throughput or capacity calculations.
Lab on the Mac mini
Lab connection
—
Passed drill rows
0
Export timestamp
—
Comparable overlays
0
Lab A1 is still validating hardware calibration and its edge/supplier model. The throughput sweep has not run. No live endpoint is connected.
Or paste exported JSON lines
Import stays in your browser. No files are uploaded.
Passed drill rows are shown separately. The current export lacks the full scenario and calibration metadata needed to compare with these model curves. Importing a row does not certify hardware performance.
For operators
What each group of dials does to the answer.
Nothing here needs the fabric's internals. Each dial is a number you already know about your plant or your fleet, and each one moves the answer in a direction you can reason about.
Access network
Pick a profile or type your own tiers. A viewer's speed grows with the upstream tier of the nodes supplying it, because each supplier sends one share through its own modem. The service-group pool is the ceiling on everything supplied from inside one group at once, and grant latency sets how long the first byte takes to arrive.
Erasure policy
k is how many pieces a chunk is cut into and how many suppliers a viewer pulls from in parallel. Parity is the spare pieces: it sets how many nodes can be lost before an object is unreadable, and the storage overhead you pay for that. "Supplier request" is how many nodes the edge asks per chunk. Asking all of them is fastest on a LAN and wasteful on a cable segment, where the losing shares still burn upstream.
Fleet
Node count and storage per node give usable capacity after coding overhead and a 20% repair reserve. The serving edge is the node that reassembles chunks for a viewer; that step decodes, so its hardware caps every policy. Suppliers never decode, so cheap nodes are fine as suppliers. Wi-Fi nodes supply slower and are ranked below wired ones.
Demand and placement
Viewers per group is the load on one service group. Keeping shares in the viewer's group keeps traffic off the hub, but every supplier then draws from the same upstream pool. Spreading shares can use spare upstream elsewhere when demand is uneven, but consumes transport between groups. With equal demand in all groups, it redistributes load without increasing total upstream capacity.
Method
How the numbers are produced.
Two kinds of figure appear on this page, and they are always labelled. Model figures come from the formula below and update as you move the dials. Measured figures come from imported Lab A1 drill exports and appear in a separate results table. Curve overlays remain disabled until exact scenario and calibration metadata are available. A model figure is never presented as a measurement.
The model Model
One viewer's rate is the smallest of three limits:
per viewer = min( k × supplier upstream, viewer downstream, edge decode )
A service group's aggregate is the smallest of four:
group = min( viewers × per viewer, upstream pool ÷ over-request, downstream pool, edges × decode )
Over-request is how many shares are asked for per share needed (7/5 = 1.4× when asking all of a 5-of-7). "Spread" placement divides supplier load across all groups; each group also serves the others. This model assumes equal demand everywhere, so it claims no extra upstream capacity from that redistribution. Time to first byte adds 1.5 grant latencies, one share transfer and one chunk decode. Wi-Fi nodes are capped at the profile's wireless rate.
Measured points Measured
OMT Lab A1 is validating an emulated fleet on a Mac mini. Network checks and hardware calibration are separate gates; a successful setup check is not a completed content-delivery sweep or proof of real-board performance.
This page imports exported JSON lines locally. It accepts only rows marked ok with byte-exact delivery, a matching drill object and a passed drill. Invalid, failed and dry-run rows are excluded. Import does not imply live status, independent review or hardware calibration.
What is a placeholder
Pi 4 decode, 14.6 MB/s is a reference supplied with this simulator; its provenance has not yet been verified by Lab A1. It is not a certified hardware ceiling.
Pi 5 and gateway decode ceilings are placeholders until a real Pi 5 with NVMe and a development gateway are benched. Figures built on them are marked in the assumptions strip.
DOCSIS profiles are starting figures. They should be replaced by the operator's real per-tier and pool numbers before any planning use.
Not modelled: the cable physical layer, plant conditions, and thermal throttling. These are exploratory estimates, not lower bounds or guarantees. Competing subscriber traffic, transport contention, loading and repair can reduce delivery.