Large-Scale Showcases¶
Three packaged workloads exercise full-day LEO analysis on server-class hardware. EX04 and EX09 use a 1,584-satellite shell for separate global-coverage and routed-service studies. The Starlink-scale reference combines exact global coverage and regional routed service for a published 3,360-satellite shell at a finer 60-second cadence.
The two 1,584-satellite examples were executed from an installed, source-free
Astraeus 0.3.0-alpha.5 candidate. The 3,360-satellite reference used a clean
checkout of exact revision 3d2a5c99 with the frozen dependency lock and
Astraeus 0.3.0-alpha.11. All ran on the same Ubuntu x86-64 VPS class with eight
logical CPUs, 30.6 GiB memory, SSD storage, and CPython 3.11.14. Treat these as
host- and workload-specific planning observations, not fixed performance
guarantees.
Qualification Snapshot¶
| Evidence | Global coverage batch | Routed service network | Starlink-scale reference |
|---|---|---|---|
| Successful cases/runs | 3/3 | 1/1 | 1/1 |
| Spacecraft / cadence | 1,584 / 120 s | 1,584 / 120 s | 3,360 / 60 s |
| Wall time | 668.45 s (11.14 min) | 1,145.26 s (19.09 min) | 2,054.37 s (34.24 min) |
| Peak process-family RSS | 16.39 GiB | 5.02 GiB | 8.88 GiB |
| Written output | 1.89 GB | 1.11 GB | 3.48 GB |
Plan compute and storage around the measured envelope, with headroom for the operating system and platform variation. The 1,584-satellite coverage batch has the largest measured memory requirement; the 3,360-satellite integrated reference has the longest measured wall time.
Preflight Before Execution¶
Memory preflight uses the resolved RunSpec dimensions to estimate the active process working set before stage execution. The current model projects 17.13 GiB for each large coverage child and 6.03 GiB for the routed service network, compared with observed peaks of 16.39 GiB and 5.02 GiB respectively.
Run the individual case dry-run before committing to the full workload:
astraeus run \
astraeus-resources/examples/user/cases/large-leo-global-coverage-elevation-10.yaml \
--dry-run
astraeus run \
astraeus-resources/examples/user/large-leo-service-network.yaml \
--dry-run
astraeus run \
astraeus-resources/examples/user/studies/starlink-scale-reference/reference-24h.yaml \
--dry-run
The other two coverage children have the same population, grid, duration, and
cadence. Plan the batch with one worker so only one large child is active at a
time. Review the reported projected_peak, threshold, status, and
recommendations against the machine that will execute the study. The qualified
Starlink-scale reference preflight projected 10.25 GiB peak memory, compared
with an observed 8.88 GiB process-family peak.
Global Coverage Sensitivity¶
large-leo-global-coverage.yaml is a serial three-case batch. Every child case
retains the 1,584-satellite shell, 24-hour timeline, 5° global grid, and
120-second reporting cadence; the terminal elevation mask changes from 10° to
25° to 40°.
astraeus batch plan \
astraeus-resources/examples/user/large-leo-global-coverage.yaml
astraeus batch run \
astraeus-resources/examples/user/large-leo-global-coverage.yaml \
--workers 1
Serial execution bounds the number of large coverage grids resident at once. The qualified results show a coherent reduction in covered-surface fraction as the elevation requirement tightens:
| Minimum elevation | Covered-surface fraction |
|---|---|
| 10° | 93.74% |
| 25° | 86.60% |
| 40° | 84.36% |
The batch summary is the comparison entry point. Each child run also retains its own manifest, state timeline, pointwise coverage data, represented-area summary, and gap statistics for deeper inspection.
Large Routed Service Network¶
large-leo-service-network.yaml couples the shell to three bounded demand
regions, two separated gateways, and sparse Walker-adjacent ISLs. It is a
single core RunSpec, so the Console can open its geometry, routes, timelines,
and Analysis artifacts directly.
astraeus run \
astraeus-resources/examples/user/large-leo-service-network.yaml \
--run-id large-leo-service-network \
--strict
The qualified run delivered all admitted demand. Sparse routing was material to the result:
| Network KPI | Qualified result |
|---|---|
| Delivery success | 100% |
| Paths using more than one hop | 82.06% |
| Mean hops | 2.54 |
| p95 hops | 5 |
| Maximum hops | 7 |
Review transport/transport_summary.json for the delivery ledger,
transport/isl_summary.json for topology state, route artifacts for selected
paths, and the global latency histogram for timing. Gateway and regional KPI
tables show where the admitted traffic entered and left the network.
Starlink-Scale Integrated Reference¶
The companion reference reconstructs the published 525 km, 53°, 28-plane, 120-satellite-per-plane shell from FCC DOC-390793A1. Its service regions, gateways, traffic, RF profiles, scheduler, and Walker-adjacent ISLs are explicit hypothetical Astraeus inputs rather than claims about Starlink operations.
astraeus run \
astraeus-resources/examples/user/studies/starlink-scale-reference/reference-24h.yaml \
--run-id starlink-scale-reference-24h \
--strict
The qualified run retained exact coverage summaries for 2,592 global points and routed 593,692 regional point-steps. Equal-point and represented-area global coverage were 77.69% and 93.92%. All routed point-steps succeeded under the study assumptions; mean and p95 latency were 61.67 ms and 86.99 ms, with 3.13 mean hops and 9 maximum hops.
Use this study when the engineering question needs the published 3,360-satellite geometry, global coverage and routed service in one run, or 60-second cadence. EX09 remains the smaller, faster 1,584-satellite routed-service showcase.
Operational Review¶
Give the run a dedicated output root and keep the monitor available throughout execution:
astraeus monitor serve --runs-root runs
After completion, verify the run or grouped manifest first, then review warning and degraded-stage counts before interpreting KPIs. Use deterministic review and report commands for a portable summary; open the same saved evidence in the Console for spatial and time-dependent inspection.
For a shorter coupled study suitable for learning the full interpretation workflow, use the Integrated Constellation Case Study.