Docs — server benchmarks

One page with benchmark and live-usage numbers for the servers on the home tailnet, last updated 2026-11-07 03:14 UTC. It refreshes itself every 15 minutes.

What it covers

Six Linux servers, named by their LAN address: .15 (debian-15), .8 (debian8) and .43 (r630-4x) on the tailnet, plus .21 (dell-r630-2x), .7 (debian-7) and .6 (debian-6) on the LAN (reached through debian8's subnet route). The summary is split in two tables: Capacity (fixed specs — CPU, frequency, cores, RAM, main-disk size, and the PassMark CPU Mark for the CPU model) and Current (live percentages — CPU load, RAM and disk use — plus the latest benchmark runs). Each machine's section below is split the same way: Hardware & capacity (what the machine is and how fast its parts are) and Current usage (load, memory, disk and network right now, plus top processes).

Not covered: mac-mini-3 is online on the tailnet but SSH is closed (Remote Login is off), .4 (192.168.68.4) doesn't answer SSH, and the two laptops and the iPhone are offline.

How each number is measured

• CPU multi — SHA-256 hashing throughput with every core busy for 5 seconds (single-core figure uses one core). Raw compute only; it says nothing about any specific app.
• PassMark — the PassMark CPU Mark for the CPU model, looked up on cpubenchmark.net (checked 2026-11-06). It is per CPU (per socket); dual-socket machines score higher as a whole system. It lets you compare these machines with any other CPU on the same scale.
• Main disk — the whole physical disk holding the root filesystem, found by walking up from / to the disk device. The root filesystem is only a partition, so the disk total is bigger than the / size; used is the sum of every local filesystem on that disk.
• CPU load % — the 1-minute load average divided by the thread count. 100% means every thread is busy.
• Memory bench — writing then copying a 256 MB block in RAM.
• Disk write — sequential write of a 1 GB file, forced to disk with fsync. Disk read — sequential read of the same file with direct I/O, so the result measures the disk rather than the page cache. The test file is deleted after each run.
• Net down / latency — a 50 MB download from Cloudflare's speed test, plus the TCP connect time to the same host.
• Services — systemd services currently running (system and user scope), excluding base-system units (cron, ssh, journald, login, time sync and the like), plus any failed units and running Docker containers. Collected with systemctl list-units.
• Load, memory, disk, network usage — a snapshot taken at collection time: 1/5/15-minute load averages, memory used vs available, filesystem usage, and network transfer rates sampled over one second.

These are indicative numbers from a quick, lightweight run — not certified benchmarks. A busy machine or a slow moment on the internet link will move them.

How it is published

The site is static files, rebuilt and redeployed every 15 minutes:

bench.py  →  collects hardware, benchmarks and usage on each server
             (over SSH through the Tailscale tunnel; LAN machines via
             debian8's subnet route)
build.py  →  renders the numbers into the site pages, and copies in the
             ClinStats and SvelteTV apps
cf-pages-deploy  →  uploads the files to the Cloudflare Pages project
             "avidys" — served at avidys.pages.dev
cron (every 15 min)  →  runs run.sh, which repeats the three steps above;
             the servers page also auto-reloads every 15 minutes

Collection runs as the avidys user with the SSH key authorized on each server, no root needed, no extra packages installed. The scripts live in ~/workspace/server-benchmarks/ (bench.py, build.py, collect.sh, run.sh).

Cloudflare Pages serves the site publicly — anyone with the link can read these pages. The benchmark numbers contain no secrets, only hostnames, specs and usage.

Other sites on this Cloudflare account

Each is its own Pages project with its own address: clinstats (clinstats.pages.dev), sveltetv (sveltetv.pages.dev), bay-area-hikes (bay-area-hikes.pages.dev), kaiser-bay-area-facilities (kaiser-bay-area-facilities.pages.dev). The first two now also live here, under /clinstats/ and /stelvet/ — the standalone addresses still work.

← Back to Avidys