MIP 12 - Decrease Vote Pace

Sydney AU testnet validator — corroborating snapshot

@ColinkaMalinka thanks for the Japan numbers — they line up closely with what we see from Sydney on the same v0.14.5 release.

For transparency: unlike your dedicated 7-day Prometheus tunnel, we don’t yet have local time-series storage on the Sydney side — we push to the Foundation OTEL endpoint but read back only the current rolling window from our local otelcol exporter. Numbers below are a point-in-time snapshot averaged across 3 readings 60 s apart (variance ≤5 ms on the percentiles).

Sydney testnet (val_id 267), 19 h since v0.14.5 restart

Metric Value
vote_delay_ready_after_timer_start_p50_ms (5min rolling) 105–110 ms
vote_delay_ready_after_timer_start_p90_ms 140–145 ms
vote_delay_ready_after_timer_start_p99_ms 240–245 ms
raptorcast_udp_primary_broadcast_latency_p99_ms (30s rolling) 141–202 ms

Timeout-cert fraction (cumulative since process start, 19 h window):

enter_new_round_tc / (enter_new_round_tc + enter_new_round_qc) = 4293 / 171516 ≈ 2.50 %

Within 0.3 pp of the Japan 24 h figure (2.78 %). Two independent APAC operators on different latency profiles arriving at nearly the same TC rate is a meaningfully consistent signal, not a one-off.

Read against the 300 ms proposal

Our p99 vote-delay of 245 ms uses 61 % of the 400 ms budget today and would use 82 % of a 300 ms budget (~55 ms margin). @ColinkaMalinka’s Japan node sits at ~89 % (~34 ms margin). Both APAC samples land in the 80–90 % budget zone where the vote-aggregation tail starts to matter — and our TC fraction has been stable at 2.5 % specifically because the current 400 ms accommodates that tail.

+1 on the same ask

Strongly seconding the request for the Foundation to publish current p99 leader-round latency by geography at 400 ms before MIP-12 is locked. Two APAC data points now (Sydney, Japan); a network-wide geo breakdown will tell whether the 300 ms target stays inclusive for the operator distribution MIP-9 (active-set 200 → 250) is encouraging.

Happy to share raw OTEL output if useful.