Investigate WireGuard tunnel throughput cap between blaze and ccnet-wi-fw (~264 Mbit/s, well under 1gig) #42

New issue

Open

opened 2026-07-24 19:08:48 +00:00 by claude-bot · 0 comments

claude-bot commented

2026-07-24 19:08:48 +00:00

Collaborator

While scoping the initial seed for issue #24's second borg client (swarm-cephfs-wi), measured real throughput across the site-to-site WireGuard tunnel (blaze ↔ ccnet-wi-fw) with iperf3 run directly between the actual endpoints of the borg push (swarm-mgr-01 → ccnet-wi-borgbackup, 10.10.10.211 → 10.20.10.253), 2026-07-24:

10s run: 329 Mbit/s avg
30s run (more reliable): 264 Mbit/s avg, stable

Expected something closer to ~1gig given the WI site's own fiber connection. The gap wasn't investigated — most likely candidate is single-threaded WireGuard crypto overhead on one of the two router endpoints (blaze or ccnet-wi-fw) rather than either site's raw link capacity, but that's a guess, not confirmed.

Not blocking anything — 264 Mbit/s is entirely workable for the borg offsite-copy use case (see ~/.claude/plans/quiet-mirroring-compass.md's "Tunnel throughput" section for the full measurement). Filed as a lower-priority follow-up to revisit when there's time: check CPU/core utilization on both router endpoints during a saturated transfer, look at WireGuard's known single-threaded-per-peer limitation, consider multiple parallel streams / multiple tunnels if it's a real constraint for something in the future, or just confirm there's nothing actually wrong and this is normal for the hardware involved.

Related: issue #24, docs/ccnet-wi-site.md, docs/hetzner-vps.md (documents the other WireGuard hub blaze runs, useful if this turns out to be a blaze-side CPU/crypto limitation rather than something specific to the WI tunnel).

While scoping the initial seed for issue #24's second borg client (`swarm-cephfs-wi`), measured real throughput across the site-to-site WireGuard tunnel (`blaze` ↔ `ccnet-wi-fw`) with `iperf3` run directly between the actual endpoints of the borg push (swarm-mgr-01 → `ccnet-wi-borgbackup`, `10.10.10.211` → `10.20.10.253`), 2026-07-24: - 10s run: 329 Mbit/s avg - 30s run (more reliable): **264 Mbit/s avg, stable** Expected something closer to ~1gig given the WI site's own fiber connection. The gap wasn't investigated — most likely candidate is single-threaded WireGuard crypto overhead on one of the two router endpoints (`blaze` or `ccnet-wi-fw`) rather than either site's raw link capacity, but that's a guess, not confirmed. Not blocking anything — 264 Mbit/s is entirely workable for the borg offsite-copy use case (see `~/.claude/plans/quiet-mirroring-compass.md`'s "Tunnel throughput" section for the full measurement). Filed as a lower-priority follow-up to revisit when there's time: check CPU/core utilization on both router endpoints during a saturated transfer, look at WireGuard's known single-threaded-per-peer limitation, consider multiple parallel streams / multiple tunnels if it's a real constraint for something in the future, or just confirm there's nothing actually wrong and this is normal for the hardware involved. Related: issue #24, `docs/ccnet-wi-site.md`, `docs/hetzner-vps.md` (documents the *other* WireGuard hub blaze runs, useful if this turns out to be a `blaze`-side CPU/crypto limitation rather than something specific to the WI tunnel).

claude-bot added the

infra

p:low

labels

2026-07-24 19:08:57 +00:00

claude-bot referenced this issue

2026-07-25 14:15:29 +00:00

ccnet-WI: add a borg backup target on the QNAP alongside the PBS replica #24