ecc.

A planet-scale cosmic-ray sensor network using Error-Correcting-Code (ECC) memory as our detector.

Pre-alpha   gathering baseline data on our own nodes before public launch

Open the live globe →

Our network right now

hosts alive
DIMM sticks watched
correctable errors (1h)
uncorrectable errors (1h)

Auto-updates every 60 seconds. Heartbeats fire hourly per stick; events post when ce>0 or ue>0.

Humanity's distributed canary in a coal mine

Every server with ECC memory is already an unwitting cosmic-ray detector. Through Hamming's error-correcting codes — invented by Richard Hamming at Bell Labs in 1950 because "two errors a week was just unacceptable" on their relay computer — our memory controllers detect and correct billions of bit-flips per year worldwide. Each one is a high-energy particle striking silicon, recorded by the kernel's Error-Detection-And-Correction (EDAC) subsystem at /sys/devices/system/edac/, then thrown away by every sysadmin who's not us.

We don't throw it away. We collect it, distill it, and share it. Distributed across hundreds of latitudes, altitudes, and continents — the first time humanity has assembled an existing-infrastructure cosmic-ray detector network at this scale. Every ECC Random-Access-Memory (RAM) server on the planet is a potential pixel. There are tens of millions of them.

The particles we measure don't just affect server RAM. They affect aerospace electronics, satellites, hospital equipment, automotive Electronic-Control-Units (ECUs), every embedded chip exposed to sky. ECC is the first wave of silicon with built-in self-monitoring; the rest of our civilization's electronics are downstream. If something is hurting our Dual-In-line-Memory-Modules (DIMMs) at scale, something is starting to hurt everything. Our network is positioned to see it first.

Why ECC RAM is the right sensor

Richard Hamming's 1950 paper introduced single-error-correcting codes — extra parity bits arranged so a single bit-flip can be detected, located, and silently corrected. The extended-Hamming Single-Error-Correcting-Double-Error-Detecting (SECDED) variant is what virtually every modern ECC memory controller implements.

Every server-class machine on Earth ships with this silicon doing Hamming-derived math billions of times per second. The hardware is already detecting bit-flips; the kernel is already counting them. The only missing piece is the network that aggregates the counts and looks for patterns — that's us. Zero new hardware, fits the permacomputer ethos: use what already exists.

Moving servers — cars, robots, drones, satellites

ECC RAM doesn't sit still. Teslas have ECC compute in their Full-Self-Driving (FSD) stacks. High-end drones use NVIDIA Jetson AGX with ECC enabled. Aircraft avionics, hospital infusion pumps, automotive ECUs — anything safety-critical. And the sky: CubeSats and orbital stations have ECC by mandate, because at Low-Earth-Orbit (LEO) altitude one cosmic ray hits with about 300-1000× the flux it has at sea level.

Our pipeline handles intermittent connectivity (queue + retry with 7-day backfill), so a drone offline for a week flushes on landing, a Tesla through dead zones backfills cleanly, a CubeSat queues through Earth-shadow side and flushes over the next ground pass.

One LEO node is worth roughly 100-1000 ground nodes for detecting Solar-Energetic-Particle (SEP) bursts — they're above most of the atmospheric shielding that drowns our signal at the surface. A Starlink-scale orbital mesh, if ever participating, would dwarf every science satellite ever built combined for cosmic-ray purposes.

The micronova question

Mainstream solar physics tracks the cycle, X-class flares, and ground-level enhancements during major SEP events. The Sun's variability is generally well-understood. The contested micronova hypothesis — periodic minor novas tied to galactic current-sheet crossings, possibly approaching — sits outside mainstream consensus. We are not endorsing it.

We are sysadmins, scientists, and curious citizens who'd rather have data than not have data. If the Sun behaves exactly as predicted forever: we have the largest open dataset of cosmic-ray ground flux ever assembled. If it behaves anomalously: we're positioned to be the first to notice. Either outcome justifies the network. Measure first, conclude later.

How to participate

Our agent is in development. When it ships, expect a one-liner along these lines:

# Coming soon — do not run yet curl -s https://ecc.unturf.com/install.sh | sh

Our agent is a Portable-Operating-System-Interface (POSIX) shell script (single file, ~800 lines, no daemon, no compiled dependencies). It runs on any Linux box with ECC RAM. It tails our EDAC counters, buckets events by minute per stick, always writes a local Tab-Separated-Values (TSV) log (useful even if you never join our network), and optionally posts anonymized aggregates back to us.

Want to follow progress or contribute code? See our source repo and DESIGN.md.

Privacy & anti-extraction

What we always do

  • Open-source agent and proxy (auditable)
  • Hash every identifier (host, stick) with a salt our agent generates on your box
  • Bucket geography wide (continent-scale region, altitude band)
  • Rate-limit at our edge only (no auth needed)
  • Publish daily anonymized data dumps so anyone can mirror

What we never do

  • Store hostnames, Internet-Protocol (IP) addresses, or exact locations
  • Require accounts, Application-Programming-Interface (API) keys, or login
  • Sell data or use it for advertising
  • Lock our software as proprietary
  • Refuse a withdrawal request

How much work does the agent do?

Tiny. No background daemon, pure cron-driven. Per-minute tick reads EDAC sysfs files, diffs a state file, posts a per-event Hyper-Text-Transfer-Protocol-Secure (HTTPS) request only if CE or Uncorrectable-Error (UE) counts increased — typically ~20-50 ms wall, zero network when memory is happy. Per-hour heartbeat posts per-stick {minutes, ce, ue} for the previous hour always, even all-zero — ~200-500 ms wall, 16-24 small JavaScript-Object-Notation (JSON) requests.

Daily totals for a typical healthy host: ~45 s Central-Processing-Unit (CPU) time, ~1 KB local log, ~25 KB network, 0 background RAM.

Verdict thresholds

Each stick earns a verdict based on accumulated observation:

VerdictTrigger
unknown< 2880 minutes observed (~2 days)
failingany UE ever, OR CE rate >10× altitude baseline AND accelerating
watchCE rate >3× altitude baseline OR above baseline AND accelerating
healthynone of the above

UE events short-circuit straight to failing regardless of observation window.

The science

Government cosmic-ray neutron monitors cover roughly 50 fixed stations worldwide. A distributed citizen-owned network could cover thousands of points across every continent and altitude band, giving finer geographic and temporal resolution than what currently exists publicly.

What we hope to measure:

How many nodes to actually detect a CME?

Honest math. Real-world ECC fleet studies (Google 2009, Facebook 2015) report ~0.1 CE per terabit per day from cosmic background — so a 384 GB host (~3 Tb) sees about 0.4 CE per day. A major SEP event might double that briefly.

Statistical floor (5σ detection)

To detectCammy-equivalent hosts
10× spike (X-class Ground-Level-Enhancement (GLE))~250 hosts
2× spike (M-class SEP)~1,000 hosts
10% Forbush decrease (GCR dip during a CME)~100,000 hosts

Coincidence detection — multiple DIMMs in one chassis hit in the same minute = almost certainly a single cosmic shower. Counting coincidences instead of raw CEs roughly quarters the hosts we need: ~50-100 geographically-distributed hosts could detect an X-class event.

Geographic spread matters more than count. 100 hosts spread across latitudes and altitudes beats 1,000 in one basement. Carrington-class detection at ~100 hosts would be a genuine scientific contribution — we may go years without one, but our network would be ready.

How it fits together

Three repos, one mission:

This mirrors our blobrand.com pattern: client lives in its own repo (deskblob), central aggregation lives in proxy.unturf.com.