|
| 1 | +SELECT |
| 2 | + client.Geo.CountryCode as country_code, |
| 3 | + client.Geo.city as city, |
| 4 | + client.Network.ASNumber as asn, |
| 5 | + COUNT(*) as sample_count, |
| 6 | + |
| 7 | + -- ============================================================================ |
| 8 | + -- PERCENTILE LABELING CONVENTION FOR IQB QUALITY ASSESSMENT |
| 9 | + -- ============================================================================ |
| 10 | + -- |
| 11 | + -- For "higher is better" metrics (throughput): |
| 12 | + -- - Raw p95 = "95% of users have ≤ X Mbit/s" |
| 13 | + -- - Label: OFFSET(95) → download_p95 (standard statistical definition) |
| 14 | + -- - Interpretation: top ~5% of users have > p95 throughput |
| 15 | + -- |
| 16 | + -- For "lower is better" metrics (latency, packet loss): |
| 17 | + -- - Raw p95 = "95% of users have ≤ X ms latency" (worst-case typical) |
| 18 | + -- - We want p95 to represent best-case typical (to match throughput semantics) |
| 19 | + -- - Solution: Invert labels - use raw p5 labeled as p95 |
| 20 | + -- - Label: OFFSET(5) → latency_p95 (inverted!) |
| 21 | + -- - Interpretation: top ~5% of users (best latency) have < p95 |
| 22 | + -- |
| 23 | + -- Result: Uniform comparison logic where p95 always means "typical best |
| 24 | + -- performance" rather than "typical worst performance" |
| 25 | + -- |
| 26 | + -- NOTE: This creates semantics where checking p95 thresholds asks |
| 27 | + -- "Can the top ~5% of users perform this use case?" - empirical validation |
| 28 | + -- against real data will determine if this interpretation is appropriate. |
| 29 | + -- ============================================================================ |
| 30 | + |
| 31 | + -- Download throughput (higher is better - NO INVERSION) |
| 32 | + -- Standard percentile labels matching statistical definition |
| 33 | + APPROX_QUANTILES(a.MeanThroughputMbps, 100)[OFFSET(1)] as download_p1, |
| 34 | + APPROX_QUANTILES(a.MeanThroughputMbps, 100)[OFFSET(5)] as download_p5, |
| 35 | + APPROX_QUANTILES(a.MeanThroughputMbps, 100)[OFFSET(10)] as download_p10, |
| 36 | + APPROX_QUANTILES(a.MeanThroughputMbps, 100)[OFFSET(25)] as download_p25, |
| 37 | + APPROX_QUANTILES(a.MeanThroughputMbps, 100)[OFFSET(50)] as download_p50, |
| 38 | + APPROX_QUANTILES(a.MeanThroughputMbps, 100)[OFFSET(75)] as download_p75, |
| 39 | + APPROX_QUANTILES(a.MeanThroughputMbps, 100)[OFFSET(90)] as download_p90, |
| 40 | + APPROX_QUANTILES(a.MeanThroughputMbps, 100)[OFFSET(95)] as download_p95, |
| 41 | + APPROX_QUANTILES(a.MeanThroughputMbps, 100)[OFFSET(99)] as download_p99, |
| 42 | + |
| 43 | + -- Latency/MinRTT (lower is better - INVERTED LABELS!) |
| 44 | + -- ⚠️ OFFSET(99) = worst latency = top 1% worst users → labeled as p1 |
| 45 | + -- ⚠️ OFFSET(5) = 5th percentile = best ~5% of users → labeled as p95 |
| 46 | + APPROX_QUANTILES(a.MinRTT, 100)[OFFSET(99)] as latency_p1, |
| 47 | + APPROX_QUANTILES(a.MinRTT, 100)[OFFSET(95)] as latency_p5, |
| 48 | + APPROX_QUANTILES(a.MinRTT, 100)[OFFSET(90)] as latency_p10, |
| 49 | + APPROX_QUANTILES(a.MinRTT, 100)[OFFSET(75)] as latency_p25, |
| 50 | + APPROX_QUANTILES(a.MinRTT, 100)[OFFSET(50)] as latency_p50, |
| 51 | + APPROX_QUANTILES(a.MinRTT, 100)[OFFSET(25)] as latency_p75, |
| 52 | + APPROX_QUANTILES(a.MinRTT, 100)[OFFSET(10)] as latency_p90, |
| 53 | + APPROX_QUANTILES(a.MinRTT, 100)[OFFSET(5)] as latency_p95, |
| 54 | + APPROX_QUANTILES(a.MinRTT, 100)[OFFSET(1)] as latency_p99, |
| 55 | + |
| 56 | + -- Packet Loss Rate (lower is better - INVERTED LABELS!) |
| 57 | + -- ⚠️ OFFSET(99) = worst loss = top 1% worst users → labeled as p1 |
| 58 | + -- ⚠️ OFFSET(5) = 5th percentile = best ~5% of users → labeled as p95 |
| 59 | + APPROX_QUANTILES(a.LossRate, 100)[OFFSET(99)] as loss_p1, |
| 60 | + APPROX_QUANTILES(a.LossRate, 100)[OFFSET(95)] as loss_p5, |
| 61 | + APPROX_QUANTILES(a.LossRate, 100)[OFFSET(90)] as loss_p10, |
| 62 | + APPROX_QUANTILES(a.LossRate, 100)[OFFSET(75)] as loss_p25, |
| 63 | + APPROX_QUANTILES(a.LossRate, 100)[OFFSET(50)] as loss_p50, |
| 64 | + APPROX_QUANTILES(a.LossRate, 100)[OFFSET(25)] as loss_p75, |
| 65 | + APPROX_QUANTILES(a.LossRate, 100)[OFFSET(10)] as loss_p90, |
| 66 | + APPROX_QUANTILES(a.LossRate, 100)[OFFSET(5)] as loss_p95, |
| 67 | + APPROX_QUANTILES(a.LossRate, 100)[OFFSET(1)] as loss_p99 |
| 68 | +FROM |
| 69 | + -- TODO(bassosimone): switch to union tables `measurement-lab.ndt.ndt7_union` |
| 70 | + -- when they have been blessed as the new stable tables. |
| 71 | + `measurement-lab.ndt.unified_downloads` |
| 72 | +WHERE |
| 73 | + date >= "{START_DATE}" AND date < "{END_DATE}" |
| 74 | + AND client.Geo.CountryCode IS NOT NULL |
| 75 | + AND client.Geo.city IS NOT NULL |
| 76 | + AND client.Network.ASNumber IS NOT NULL |
| 77 | + AND a.MeanThroughputMbps IS NOT NULL |
| 78 | + AND a.MinRTT IS NOT NULL |
| 79 | + AND a.LossRate IS NOT NULL |
| 80 | +GROUP BY country_code, city, asn |
| 81 | +ORDER BY country_code, city, asn |
0 commit comments