Skip to content

the three measurements nobody could see get a surface - #3418

Merged
Flotapponnier merged 1 commit into
devfrom
feat/311-latency-views
Oct 30, 2026
Merged

Flotapponnier merged 1 commit into
devfrom
feat/311-latency-views

Conversation

@Flotapponnier

Copy link
Copy Markdown
Collaborator

the three measurements nobody could see get a surface

Of the engineer's five points, three were built and visible nowhere: the wider
method set with its archive call, the heavy eth_call, and Solana's v2 methods.
All three have been collecting for hours. None of them reached a page.

Four selectable views on bench 311, which is the keyed board by construction,
so none of them can land on a cohort that has no such data:

eth_call work          heavy leg minus light leg, the compute term alone
Archive read           round trip of a balance read 5,000,000 blocks deep
getLogs, address       what answering an address-filtered query costs
Solana v2              whether getProgramAccountsV2 is served

They read the round trip of calls the coverage pass already makes, so they
cost no additional request. The first three answer points 1 and 2; the fourth
answers the half of point 4 that was measurable.

WHY VIEWS AND NOT COLUMNS. The column list is at its cap of nine. More to the
point, a view could not carry an absent reading until today: the ledger read a
missing panel value as 0, which on a higher-is-better board is a refusal
nobody gave, and that is precisely why this bench published its capability as
columns and wrote the reason into its methodology. #3416 fixed the renderer, so
the surface the engineer actually asked for is available again. The columns
stay, since they fit nine answers on one screen; the views carry what a column
cannot, a number with a unit.

WHY NOT ON THE CHAIN RPC PAGES, which is where this information belongs and
where it will eventually go. Those pages default to the public cohort, which
has no capability data at all, so a reader landing on the default view and
clicking any of these would meet a board of dashes. Honest dashes since #3416,
and still a bad page. Filling them needs the range ladder and the capability
probe on the no-key harness, which is a larger piece, costed earlier at about
2.8 percent of that harness's existing call volume.

The eth_call view is the one to read with care for another week. The work term
measured 18 to 66 ms across eleven keyed cells, against 109 ms of dispersion
in the instrument that measured it, so it is published as a number and not yet
as a ranking anybody should act on. The hourly lane from #3412 is what will
settle that, and it is six times faster than the cadence this board runs at.

Every one of these is a COLD number: the coverage probe never reuses a
connection, so DNS, TCP and TLS are paid on each call. Their comparable is the
cold latency arm, not the warm one, and both the panel descriptions and the
methodology say so.

Cache keys move in lockstep, v123 / v116 / v61. providers-v32 deliberately
does not: no provider entered or left.

260 specs valid, tsc clean, 827 tests pass.

Of the engineer's five points, three were built and visible nowhere: the wider
method set with its archive call, the heavy eth_call, and Solana's v2 methods.
All three have been collecting for hours. None of them reached a page.

Four selectable views on bench 311, which is the keyed board by construction,
so none of them can land on a cohort that has no such data:

    eth_call work          heavy leg minus light leg, the compute term alone
    Archive read           round trip of a balance read 5,000,000 blocks deep
    getLogs, address       what answering an address-filtered query costs
    Solana v2              whether getProgramAccountsV2 is served

They read the round trip of calls the coverage pass already makes, so they
cost no additional request. The first three answer points 1 and 2; the fourth
answers the half of point 4 that was measurable.

WHY VIEWS AND NOT COLUMNS. The column list is at its cap of nine. More to the
point, a view could not carry an absent reading until today: the ledger read a
missing panel value as 0, which on a higher-is-better board is a refusal
nobody gave, and that is precisely why this bench published its capability as
columns and wrote the reason into its methodology. #3416 fixed the renderer, so
the surface the engineer actually asked for is available again. The columns
stay, since they fit nine answers on one screen; the views carry what a column
cannot, a number with a unit.

WHY NOT ON THE CHAIN RPC PAGES, which is where this information belongs and
where it will eventually go. Those pages default to the public cohort, which
has no capability data at all, so a reader landing on the default view and
clicking any of these would meet a board of dashes. Honest dashes since #3416,
and still a bad page. Filling them needs the range ladder and the capability
probe on the no-key harness, which is a larger piece, costed earlier at about
2.8 percent of that harness's existing call volume.

The eth_call view is the one to read with care for another week. The work term
measured 18 to 66 ms across eleven keyed cells, against 109 ms of dispersion
in the instrument that measured it, so it is published as a number and not yet
as a ranking anybody should act on. The hourly lane from #3412 is what will
settle that, and it is six times faster than the cadence this board runs at.

Every one of these is a COLD number: the coverage probe never reuses a
connection, so DNS, TCP and TLS are paid on each call. Their comparable is the
cold latency arm, not the warm one, and both the panel descriptions and the
methodology say so.

Cache keys move in lockstep, v123 / v116 / v61. providers-v32 deliberately
does not: no provider entered or left.

260 specs valid, tsc clean, 827 tests pass.
@Flotapponnier
Flotapponnier merged commit 6144888 into dev Oct 30, 2026
2 checks passed
@Flotapponnier
Flotapponnier deleted the feat/311-latency-views branch November 3, 2026 11:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant