Skip to content

CONCEPT Cited by 1 source

Trimean aggregation

The trimean is a single-number summary of a distribution defined as a weighted average of Q1, the median, and Q3:

trimean = (Q1 + 2 · median + Q3) / 4

Equivalently: "average of the median with itself, with Q1, and with Q3". It's a robust estimator of central tendency that gives a little more weight to the median than to Q1/Q3, and it explicitly ignores the tails.

Why it's used for latency ranking

From the canonical wiki source (Source: sources/2026-04-17-cloudflare-agents-week-network-performance-update):

"We calculate our rankings using the trimean of connection times. The trimean is a weighted average of three values: the first quartile (25th percentile), the median (50th percentile), and the third quartile (75th percentile). This approach smooths out noise and outliers, giving us a cleaner signal about the typical user experience rather than an extreme case that might skew the picture."

Compared to alternatives:

  • Arithmetic mean — dominated by outliers. A single 30-second stuck handshake moves the mean dramatically; one bad socket shouldn't decide a provider ranking.
  • Median alone — robust but throws away information about the spread in the middle 50 %. Trimean keeps the shape signal that Q1 and Q3 carry.
  • Single percentile (p90, p95, p99) — noisier than trimean on the same sample count; measures tails, not typical.
  • Geometric mean — closer to trimean for many latency distributions but harder to explain and less robust to a Q1 that's close to zero (e.g. sub-millisecond LAN-ish measurements).

What it explicitly does not capture

The trimean discards everything below Q1 and above Q3 — so:

  • No tail information. p95, p99, or worst-case latency can be orders of magnitude higher and the trimean ranking won't move. For systems where user-perceived worst case matters (real-time interactive applications, tail-call RPC fanouts → see concepts/tail-latency-at-scale), a trimean comparison is structurally misleading.
  • No bimodality signal. A distribution that's half at 5 ms and half at 500 ms (cold vs. warm path, for example) can have the same trimean as a tight 100-ms distribution — with a radically different user experience. Trimean flattens modes into a central-tendency number.
  • No variance signal. Q3 − Q1 (the IQR) is a dispersion number the trimean absorbs but doesn't expose. Reporters should publish IQR alongside trimean; Cloudflare's performance posts typically only publish the trimean.

When trimean is the right choice

  • Provider / network ranking on the median user's experience — what % of networks does Cloudflare win on typical experience? Trimean on connection time is the right primitive here, and it's what the 40 % → 60 % ranking in the 2026-04-17 post is measured on.
  • Noise-tolerant continuous dashboards — trimean is stable under single-sample outliers so a live graph of "provider trimean latency by country" is readable at a glance without bot-traffic / measurement-error spikes dragging it around.

When trimean is the wrong choice

  • Worst-case SLA compliance — use p95 / p99 directly.
  • Fan-out / tail-call sensitive workloads — the user waits for the slowest of N parallel requests; the mean of the max is what matters, not the trimean of a single request. See concepts/tail-latency-at-scale.
  • Bimodal distributions — report both modes, or the fraction in each.

Relation to other robust estimators

  • Median / 50th percentile — trimean's centre of mass; 2×-weight in the formula.
  • Midhinge — (Q1 + Q3) / 2, the unweighted sibling that matches trimean when median = midhinge.
  • Tukey's fences — the IQR-based outlier rule (Q1 − 1.5·IQR, Q3 + 1.5·IQR) complements trimean for flagging the samples trimean is discarding; pair them when exploring a distribution.

Seen in

Last updated · 200 distilled / 1,178 read