## What's wrong?

On a multi-gigabit link, `omarchy-network-speedtest down` under-reports by 2-4x
while `up` is accurate. The cause is not the local link, the NIC, or the sampling
loop: it is that the fast.com Open Connect Appliances the script downloads from
will not serve a single client anywhere near multi-gigabit rates, while the
upload direction POSTs to those same nodes and is discarded cheaply at the edge.

The two directions are therefore not measuring comparable work, and only the
download side is affected.

## Evidence

3 Gbps symmetric fibre, RTL8125 2.5GbE NIC (`r8169`), so the port ceiling is
~2350 Mbps of TCP payload. A browser speed test on the same machine reports
**2290 down / 2181 up**.

The plugin, same machine, minutes apart:

```
$ omarchy-network-speedtest down
778 701 402 349 409 614 642 609 679 757 706

$ omarchy-network-speedtest up
2000 2306 2239 2319 2370 2344 2370 2369 2369 2370 2370
```

Upload sits at the port's line rate. Download is 3-6x lower and swings wildly.
No `0.0` samples and no stuck workers, so this is distinct from #10768.

Isolating server from method — identical 8-worker round-robin loop, measured off
`/sys/class/net/<if>/statistics/rx_bytes` over an 8s window after a 2s warmup:

| Target | Workers | Result |
|---|---|---|
| fast.com OCA, 3 nodes (script default) | 8 | 606 Mbps |
| fast.com OCA, 3 nodes | 16 | 766 Mbps |
| fast.com OCA, 5 nodes | 24 | 734 Mbps |
| fast.com OCA, single node | 8 | 927 Mbps |
| **Cachefly, same loop** | **8** | **2117 Mbps** |

Same code path, same machine, same minute. The OCA nodes plateau under 1 Gbps no
matter how much parallelism is thrown at them; a well-peered CDN reaches line
rate immediately.

Two hypotheses tested and ruled out:

- **Connection setup / TCP slow start.** Each OCA request is a fresh connection
  for a fixed 25 MB payload. Reusing one connection for 6 sequential fetches via
  curl keepalive changed nothing: 925 Mbps vs 927 Mbps.
- **Payload size asymmetry** (25 MB down vs the 64 MB `dd` upload). Raising
  worker count to cover the gaps moved the number only marginally, and never
  past ~930 Mbps.

## Root cause

`traffic_worker` uses the same fast.com targets for both directions, but the
server-side cost is wildly asymmetric:

- **down** asks the OCA to actually serve 25 MB of real payload per request.
  Netflix rate-limits per-client cache egress, which is the ~600-930 Mbps
  ceiling above.
- **up** POSTs `/dev/zero` to `/speedtest`. The node accepts and discards it, so
  it absorbs whatever the client can push and the number reflects the local link.

So `up` happens to be right and `down` is measuring Netflix's willingness to
serve, not the connection. The per-node variation across the round-robin is what
produces the 349-778 swing.

## Expected

The download figure should reflect the link, not one CDN's per-client egress
policy. Options, roughly in order of preference:

1. Download from an endpoint provisioned for speed testing at multi-gigabit
   rates (Cloudflare's `speed.cloudflare.com/__down?bytes=` needs no token and
   reached line rate here).
2. Spread across many more OCA nodes than 3 — though the measurements above
   suggest this plateaus well short of line rate.
3. Failing that, label the figure honestly, since a user on a >1 Gbps plan will
   reasonably read the current number as a fault on their own connection.

Worth noting that #10768 reports "~500-700 Mbps" from manual OCA fetches as
confirmation that the link is healthy. That figure is itself the OCA ceiling, so
the same cap is likely already being misread as a baseline in that thread.

## Steps to reproduce

1. On a connection faster than ~1 Gbps, run `omarchy-network-speedtest down`
   and `omarchy-network-speedtest up`.
2. Observe upload at line rate and download at a fraction of it.
3. Re-run the same 8-worker loop against any well-peered CDN and observe it
   reach line rate.

## System details

- Omarchy 4.0.3-1
- Kernel 7.1.9-arch1-2
- Realtek RTL8125 2.5GbE, `r8169`, link 2500 Mbps, zero RX/TX errors or drops
- 3 Gbps symmetric fibre
- Script: `/usr/bin/omarchy-network-speedtest`

---

Filed by Claude Opus 5 via Claude Code.