Documentation · Releases · Hipparchus

Hipparchus — H.1.0

H.1.0 — Hipparchus

Why “Hipparchus”

Hipparchus of Nicaea (~190 BCE) was the Greek astronomer who first systematically catalogued stars by brightness and position. Where earlier astronomers grouped stars loosely, Hipparchus produced an explicit register with a magnitude scale anyone could re-derive. The H.1.0 rehaul carries the same spirit: every benchmark sub-test gets named, weighted, and shown with its baseline alongside the measured value — instead of being folded into a single synthetic “chainweb score” operators had to take on faith.

Headline features

• 8-way CPU split. CPU’s 22% slice now breaks down into eight weighted sub-tests: sysbench single-thread (4%), sysbench multi-thread (4%), IPC (2%), Blake2s (2%), secp256k1 (3%), Ed25519 (2%), pact-proxy (3%), hash-verify (2%). See /docs/scoring for the full weights table.
• RAM split into quantity (15%) and speed (4%). Quantity covers the “does this box have enough RAM” axis; speed measures memory bandwidth so a node with plenty of slow RAM does not score the same as one with the same total but faster modules.
• Network 5-subtest with chainweb-minimum baselines. Network’s 20% slice now resolves into download (8%), latency (7%), upload (3%), jitter (1%), and loss (1%) — each carrying both a 100%-baseline and a chainweb-minimum baseline so operators can see the operate-but-degraded threshold side-by-side. See /docs/scoring/network for the five-row table and the eight-region list.
• CPU quality badge. Every node now carries a four-bucket badge (strong / good / adequate / weak) derived from per-thread signals — capacity-blind, so a big-iron host with mediocre per-core performance does not get a misleading green light.
• Ghost-container CPU bench for segregated slices. Slices inherit their parent host’s CPU score via a cache keyed on (host, cpu_model, vcpu). Cache hits render instantly with an inherited attribution; cache misses enqueue a fresh ghost-CPU bench. Identical hardware always scores identically across every slice on the box.
• Per-step row contract in the UI. Every bench step renders as its own row with status, raw measurement, both baselines, normalised score, and the weighted contribution. No more single opaque number.
• Three opener-line variants per dimension. Prime fresh, segregated fresh-ghost, and segregated cached each render with their own attribution line so the operator can see at a glance how the score was produced.
• Force-fresh fleet rebench. A third action card on /hub/fleet-maintenance runs the wave model (Primes → ghost-CPU triples → optional drives → restamp) to migrate every node’s stamped score to the new formula in one operator-initiated action. See /docs/scoring/migration for the wall-time formula and runbook.
• Hub upload-sink endpoint. The new upload sub-test posts a body to a hub-side endpoint at /api/upload-sink (default https://upload.ancientholdings.eu/sink). A multi-hub forward-compat seam is in place so each node’s upload bench can target its assigned hub’s sink in a future topology.

Operator action required

• Deploy H.1.0.Pull, install, restart — the standard ship flow. The migrations shipped in this release are additive and run automatically on first boot.
• Build & push the stoa-bench image to GHCR. Until CI automation lands, the ghost-CPU bench image is pushed manually from a developer machine. The exact docker build / docker push command sequence lives in /docs/scoring/migration.
• Run “Force-fresh fleet rebench.” From /hub/fleet-maintenance, click the third action card. The confirm dialog will surface the estimated wall-time and the per-wave plan; the runbook explains how to read it. Force-fresh is what migrates every node’s stamped score to the new formula — pre-H.1.0 rows are not retroactively rescored on disk.
• Review the new ServerScores. Once the rebench wave completes, the /hub/nodes table surfaces the new per-subtest breakdown and the four-bucket CPU quality badge on every node. Treat this as the authoritative fleet picture from this point forward.

Further reading

• /docs/scoring — the master scoring chapter: weights table, 100% and chainweb-minimum baselines, reuse matrix (Prime vs Segregated per dimension), ghost-cache rule, and the four distance classifications.
• /docs/scoring/network — the network sub-chapter: 5-subtest table, the eight region list, the upload-sink endpoint contract, and the multi-hub forward-compat note.
• /docs/scoring/migration — the operator runbook: when to run Force-fresh, the wall-time formula, the manual stoa-benchbuild & push sequence, and what “no backfill” means in practice.

What did NOT change

• Disk subscore formula. The equal-thirds split across 4K-random-read, 4K-random-write, and 1M-sequential stays exactly as it shipped pre-Hipparchus. No change to disk weights, baselines, or per-drive measurement flow.
• Commitment subscore. The log-curve from committed_gbis unchanged. Prime nodes derive it from the host commitment; segregated slices derive it from the slice’s allocated commitment — same shape as before.

Rollback note

H.1.0 is forward-compatible with v.G.1.x stamped scores. Pre-Hipparchus rows already on disk continue to render under their stamped legacy scores until Force-fresh fleet rebench overwrites them. There is no schema-side migration reversal required to roll back to a v.G.1.4* binary, because the migrations shipped in this release (077, 078, and 079) only ADD columns and tables — they never DROP. Restoring a v.G.1.4* binary against a Hipparchus-migrated database leaves the new columns unused but does not break the older code paths.

If a rollback is actually performed, operators should re-run the prior formula’s Force-fresh fleet rebench under the v.G.1.4* binary to restamp every node under that formula. No manual data fix-up is needed beyond the rebench.

• ← Back to all releases