Repository navigation
four readings a day cannot say whether the work term ranks anyone - #3412
Merged
Merged
Conversation
The heavy eth_call and its light reference have been probed since #3407, on the capability cadence of once every six hours. That cadence is right for the question it was built for: whether a provider routes a method is a property of a plan and changes monthly. It is wrong for a measurement, and the work term is a measurement. Asked directly, on eleven keyed cells from a laptop, three repeats each: alchemy ethereum base arbitrum bnb polygon hyperliquid robinhood +44 to +66 ms chainstack ethereum, robinhood +56, +60 ms quicknode robinhood +39 ms chainstack arc +18 ms That is a 48 ms spread between providers against 109 ms of dispersion inside the measuring instrument, so from that vantage the honest answer is that it does not rank anything yet. The deltas are nevertheless suggestive in a way worth chasing: Arc, a young low-traffic chain, costs a fifth of what Ethereum costs for the same fifty state reads, which is exactly the "depends on hardware capacity" effect the review was pointing at. Whether the spread survives from a datacentre is a question about sample count, and sample count is the one variable a cadence controls. At four readings a day a week yields 28 points per cell. Hourly yields 168. WHAT THIS DELIBERATELY DOES NOT DO is raise the whole pass. Twelve probes hourly would cost a provider with eight EVM cells about 69,000 requests a month in this region, 19% of Infura's 370,000 budget on top of the 173,000 the tip probe already spends there. Two probes cost 11,520 for the same footprint, about 3%. The instruction that came with this was to watch the plans, and that is what watching them looks like: raise the cadence of the thing being measured, not of the thing that changes monthly. Same region as the capability pass, because a difference between two legs is the work only if both legs share a vantage point. Offset four minutes from it so the two never interleave on one endpoint, which would put a capability probe between the legs. Only a PAIR counts: a heavy reading whose light partner failed has no reference to be a difference from, and the pass line says how many endpoints produced one, so the lane's own yield is visible rather than assumed. Both legs are built through the same constructor the capability pass uses, so the verdict rule and the latency rule cannot drift between the two cadences; a test asserts it, because a delta computed across two definitions of "served" is not a delta. The cadence is tunable from Railway without a rebuild and floored at five minutes. Below that this stops measuring the provider and starts measuring what happens when we hammer it, which is both dishonest and a good way to lose a key. Mutation-checked by removing the floor. Nothing is published. This changes how often a number is taken, not whether it reaches a page. The bench this is heading for is a judgment that needs a week of real samples first, and those samples now arrive six times faster. Three tests. go build, go vet, go test clean.
Flotapponnier
added a commit
that referenced
this pull request
Oct 30, 2026
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
added a commit
that referenced
this pull request
Oct 30, 2026
…d first (#3420) Read off the published blob twenty minutes after shipping the views, which is the part no generic check covers: a new panel's values. eth_call work getblock 98.6 dwellir 51.6 blockmachine 48.8 quicknode 16.0 alchemy 7.5 chainstack -1.6 A negative work term is not a small number, it is an impossible one. Both legs are the same call through the same socket, one aggregating fifty state reads and one a single read, so the heavy leg cannot be the faster one. At an hour of samples the two averages simply crossed. On a lower-is-better view that reading does not sit quietly at the bottom: it ranks FIRST. The board would have crowned the provider whose measurement was noisiest, which is the same fault as crowning a provider for a cell nobody asked it. So the panel withholds it. The query ends in > 0, the series disappears for that provider, and the cell renders as a dash, which since #3416 means absent rather than zero. A dash here says the pair has not separated yet, which is true and useful; minus 1.6 ms says something that cannot happen. This is also the measurement I said last week needed a week before anyone acts on it. The hourly lane from #3412 is what will make the term stable; until then the honest rendering of an unstable difference is no rendering. Found by reading the values rather than by a check, which is why the audit pass exists: the deterministic checks on this bench came back 6 PASS, 1 WARN, 0 FAIL, and none of them looks at a panel added twenty minutes earlier. Cache keys move in lockstep, v124 / v117 / v62: a panel's values live in the cached entry, so the old reading would otherwise sit there for the full TTL. 260 specs valid, tsc clean, 827 tests pass.
Flotapponnier
added a commit
that referenced
this pull request
Oct 30, 2026
The adversarial audit of bench 311 came back FIX THEN SHIP, and the two
blockers it found below the worker lag share one cause: every selector on this
bench aggregates `rpc_api_supported` and `rpc_api_probe_total` with no `api`
filter. So each probe added in the last few hours silently joined the
headline, the success rate, the sample size, the rank gate and the freshness
column. I added four probes and two ladder counters and did not look at what
already summed them.
WHAT IT PUBLISHED, measured by the audit against the live blob.
The two eth_call legs write the capability gauge, so each chain contributed
nine cells where the copy describes seven:
provider published under the stated 7-cell method
Quicknode 93.06 91.07
Chainstack 95.83 94.64
GetBlock 81.94 76.79
Dwellir 91.67 89.29
BlockMachine 96.83 95.92
Every ranked headline sat 0.9 to 5.2 points high, the GetBlock to BlockMachine
gap read 19.1 where it is 14.9, and the sample said n=72 where the copy says
56. The order and the gate did not move, which is why nothing looked wrong.
The range ladder writes a probe counter and no capability gauge, so the
success denominator grew by two APIs while the numerator did not. Every ranked
row read 81.8182 percent, which is 72/88, for cells that all reached a
verdict: the figure this spec defines is 100. The tooltip then invented
failures from it, "13 failed of 72 measurements", none of which happened. On
the Robinhood tab Alchemy's unranked badge read 73 percent for what is 6 of 7.
THE FIX is an allowlist of the seven capability questions on all 67
selectors, written out rather than globbed: `eth_getlogs_(nofilter|address|
topics)` and the four others by name. A wildcard would let the next probe in
the same way, and the ladder's own counters are called `getlogs_range_*`,
which a careless `eth_getlogs_.*` would not catch today and might tomorrow.
Measurements keep their own views; they have no business in a share of cells
served.
THREE MORE FROM THE SAME AUDIT, each bounded:
The freshness column took `max by (provider)` over every api, and the eth_call
stamps are rewritten hourly while capability verdicts move every six hours. So
the column would have sat near one hour forever while a capability pass
stalled, which is the exact failure its own methodology bullet promises to
expose. It now reads the OLDEST capability stamp.
The Solana view pinned `chain="solana"` and that pin survives dimension
injection, so it rendered Solana values on every EVM tab: on the Ethereum tab
it showed chainstack 0, quicknode 0, getblock 0. The bench declares Solana out
of scope in its own methodology. The view is gone; the probe stays in the
harness for the Solana bench that owns the question.
The FAQ answered "Not yet ... planned and is deliberately absent" about the
window measurement, directly above the two columns that publish it. Rewritten
to describe the ladder.
AND TWO CORRECTIONS TO MY OWN COPY. The cadence bullet said every method is
asked every six hours; the two eth_call legs have run hourly since #3412. And
both the spec and my commit message for #3420 said the legs share one cold
connection. They do not: the cold transport sets DisableKeepAlives, so each
leg dials its own and pays its own handshake. That is not a detail, because
the handshake noise is what the difference carries, and `> 0` only removes the
half that falls below zero. The copy now says so, and the view is described as
a number rather than a ranking until the hourly lane gives it enough samples.
Cache keys move in lockstep, v126 / v119 / v64, rebased onto the v125 another
session landed while this was being written.
260 specs valid, tsc clean, 828 tests pass.
Flotapponnier
added a commit
that referenced
this pull request
Oct 30, 2026
…es no rank (#3425) * every probe added today joined the headline without being asked The adversarial audit of bench 311 came back FIX THEN SHIP, and the two blockers it found below the worker lag share one cause: every selector on this bench aggregates `rpc_api_supported` and `rpc_api_probe_total` with no `api` filter. So each probe added in the last few hours silently joined the headline, the success rate, the sample size, the rank gate and the freshness column. I added four probes and two ladder counters and did not look at what already summed them. WHAT IT PUBLISHED, measured by the audit against the live blob. The two eth_call legs write the capability gauge, so each chain contributed nine cells where the copy describes seven: provider published under the stated 7-cell method Quicknode 93.06 91.07 Chainstack 95.83 94.64 GetBlock 81.94 76.79 Dwellir 91.67 89.29 BlockMachine 96.83 95.92 Every ranked headline sat 0.9 to 5.2 points high, the GetBlock to BlockMachine gap read 19.1 where it is 14.9, and the sample said n=72 where the copy says 56. The order and the gate did not move, which is why nothing looked wrong. The range ladder writes a probe counter and no capability gauge, so the success denominator grew by two APIs while the numerator did not. Every ranked row read 81.8182 percent, which is 72/88, for cells that all reached a verdict: the figure this spec defines is 100. The tooltip then invented failures from it, "13 failed of 72 measurements", none of which happened. On the Robinhood tab Alchemy's unranked badge read 73 percent for what is 6 of 7. THE FIX is an allowlist of the seven capability questions on all 67 selectors, written out rather than globbed: `eth_getlogs_(nofilter|address| topics)` and the four others by name. A wildcard would let the next probe in the same way, and the ladder's own counters are called `getlogs_range_*`, which a careless `eth_getlogs_.*` would not catch today and might tomorrow. Measurements keep their own views; they have no business in a share of cells served. THREE MORE FROM THE SAME AUDIT, each bounded: The freshness column took `max by (provider)` over every api, and the eth_call stamps are rewritten hourly while capability verdicts move every six hours. So the column would have sat near one hour forever while a capability pass stalled, which is the exact failure its own methodology bullet promises to expose. It now reads the OLDEST capability stamp. The Solana view pinned `chain="solana"` and that pin survives dimension injection, so it rendered Solana values on every EVM tab: on the Ethereum tab it showed chainstack 0, quicknode 0, getblock 0. The bench declares Solana out of scope in its own methodology. The view is gone; the probe stays in the harness for the Solana bench that owns the question. The FAQ answered "Not yet ... planned and is deliberately absent" about the window measurement, directly above the two columns that publish it. Rewritten to describe the ladder. AND TWO CORRECTIONS TO MY OWN COPY. The cadence bullet said every method is asked every six hours; the two eth_call legs have run hourly since #3412. And both the spec and my commit message for #3420 said the legs share one cold connection. They do not: the cold transport sets DisableKeepAlives, so each leg dials its own and pays its own handshake. That is not a detail, because the handshake noise is what the difference carries, and `> 0` only removes the half that falls below zero. The copy now says so, and the view is described as a number rather than a ranking until the hourly lane gives it enough samples. Cache keys move in lockstep, v126 / v119 / v64, rebased onto the v125 another session landed while this was being written. 260 specs valid, tsc clean, 828 tests pass. * a product page claimed first place on a chain where the board publishes no rank Third blocker from the bench 311 audit, and the same shape as the badge faults removed this morning: a rank handed to a row the board itself declines to rank, and a tie resolved by whoever happens to be first in the YAML. bestPerChain took `sorted[0]` of every live row on a chain. Two live consequences. A GATED ROW WAS CROWNED. Alchemy reads 100 on the Robinhood tab and the board publishes it UNRANKED there, with its cause printed beside it: the one method it was not asked is the one the rest of the cohort refuses. The stash does not read `unrankedLabel`, so /products/alchemy rendered "#1 of 5 on Robinhood Chain" while the bench declined to rank the row. The 5 is the ranked pool, which does not contain Alchemy, so the denominator described a different set from the numerator. A TIE WENT TO SPEC ORDER. On Ethereum, Quicknode, Chainstack, Dwellir and BlockMachine all read 100. The sort is stable, so first-declared won: /products/quicknode showed "#1 of 5" on Ethereum, Base, Arbitrum, BNB Chain and Arc while three equal providers got nothing. A tie is not a ranking, and this repo spent the year removing that shape from boards. A chip is the same claim in a smaller box. So a gated row cannot lead, and a shared best value elects nobody. The conservative answer is no chip rather than a chip three others have an equal right to. The trailer end applies only the first rule: a tie for worst harms nobody, but naming a gated row the worst reads as a verdict on a row whose whole point is that it was not compared. The rule is its own module because it is two sentences that are easy to get right and easy to lose in a sixty-line loop, and because it needed the exact production cases replayed rather than a neighbouring shape. Ten tests carrying the Robinhood and Ethereum readings as they were measured. Mutation-checked by restoring `sorted[0]`, which fails five of them. Four cache keys move: bench-unfiltered-v127, all-benchmarks-v120, bench-filters-v65 and providers-v34. The last one is the point: the index feeds the chip, so a cached one keeps claiming the rank for its whole 900 s TTL. Rebased onto the v33 another session landed while this was being written. Stacked on #3424, which fixes the same audit's other two findings. 260 specs valid, tsc clean, 838 tests pass.
Flotapponnier
added a commit
that referenced
this pull request
Oct 30, 2026
…as inside the measurement (#3427) * every probe added today joined the headline without being asked The adversarial audit of bench 311 came back FIX THEN SHIP, and the two blockers it found below the worker lag share one cause: every selector on this bench aggregates `rpc_api_supported` and `rpc_api_probe_total` with no `api` filter. So each probe added in the last few hours silently joined the headline, the success rate, the sample size, the rank gate and the freshness column. I added four probes and two ladder counters and did not look at what already summed them. WHAT IT PUBLISHED, measured by the audit against the live blob. The two eth_call legs write the capability gauge, so each chain contributed nine cells where the copy describes seven: provider published under the stated 7-cell method Quicknode 93.06 91.07 Chainstack 95.83 94.64 GetBlock 81.94 76.79 Dwellir 91.67 89.29 BlockMachine 96.83 95.92 Every ranked headline sat 0.9 to 5.2 points high, the GetBlock to BlockMachine gap read 19.1 where it is 14.9, and the sample said n=72 where the copy says 56. The order and the gate did not move, which is why nothing looked wrong. The range ladder writes a probe counter and no capability gauge, so the success denominator grew by two APIs while the numerator did not. Every ranked row read 81.8182 percent, which is 72/88, for cells that all reached a verdict: the figure this spec defines is 100. The tooltip then invented failures from it, "13 failed of 72 measurements", none of which happened. On the Robinhood tab Alchemy's unranked badge read 73 percent for what is 6 of 7. THE FIX is an allowlist of the seven capability questions on all 67 selectors, written out rather than globbed: `eth_getlogs_(nofilter|address| topics)` and the four others by name. A wildcard would let the next probe in the same way, and the ladder's own counters are called `getlogs_range_*`, which a careless `eth_getlogs_.*` would not catch today and might tomorrow. Measurements keep their own views; they have no business in a share of cells served. THREE MORE FROM THE SAME AUDIT, each bounded: The freshness column took `max by (provider)` over every api, and the eth_call stamps are rewritten hourly while capability verdicts move every six hours. So the column would have sat near one hour forever while a capability pass stalled, which is the exact failure its own methodology bullet promises to expose. It now reads the OLDEST capability stamp. The Solana view pinned `chain="solana"` and that pin survives dimension injection, so it rendered Solana values on every EVM tab: on the Ethereum tab it showed chainstack 0, quicknode 0, getblock 0. The bench declares Solana out of scope in its own methodology. The view is gone; the probe stays in the harness for the Solana bench that owns the question. The FAQ answered "Not yet ... planned and is deliberately absent" about the window measurement, directly above the two columns that publish it. Rewritten to describe the ladder. AND TWO CORRECTIONS TO MY OWN COPY. The cadence bullet said every method is asked every six hours; the two eth_call legs have run hourly since #3412. And both the spec and my commit message for #3420 said the legs share one cold connection. They do not: the cold transport sets DisableKeepAlives, so each leg dials its own and pays its own handshake. That is not a detail, because the handshake noise is what the difference carries, and `> 0` only removes the half that falls below zero. The copy now says so, and the view is described as a number rather than a ranking until the hourly lane gives it enough samples. Cache keys move in lockstep, v126 / v119 / v64, rebased onto the v125 another session landed while this was being written. 260 specs valid, tsc clean, 828 tests pass. * a product page claimed first place on a chain where the board publishes no rank Third blocker from the bench 311 audit, and the same shape as the badge faults removed this morning: a rank handed to a row the board itself declines to rank, and a tie resolved by whoever happens to be first in the YAML. bestPerChain took `sorted[0]` of every live row on a chain. Two live consequences. A GATED ROW WAS CROWNED. Alchemy reads 100 on the Robinhood tab and the board publishes it UNRANKED there, with its cause printed beside it: the one method it was not asked is the one the rest of the cohort refuses. The stash does not read `unrankedLabel`, so /products/alchemy rendered "#1 of 5 on Robinhood Chain" while the bench declined to rank the row. The 5 is the ranked pool, which does not contain Alchemy, so the denominator described a different set from the numerator. A TIE WENT TO SPEC ORDER. On Ethereum, Quicknode, Chainstack, Dwellir and BlockMachine all read 100. The sort is stable, so first-declared won: /products/quicknode showed "#1 of 5" on Ethereum, Base, Arbitrum, BNB Chain and Arc while three equal providers got nothing. A tie is not a ranking, and this repo spent the year removing that shape from boards. A chip is the same claim in a smaller box. So a gated row cannot lead, and a shared best value elects nobody. The conservative answer is no chip rather than a chip three others have an equal right to. The trailer end applies only the first rule: a tie for worst harms nobody, but naming a gated row the worst reads as a verdict on a row whose whole point is that it was not compared. The rule is its own module because it is two sentences that are easy to get right and easy to lose in a sixty-line loop, and because it needed the exact production cases replayed rather than a neighbouring shape. Ten tests carrying the Robinhood and Ethereum readings as they were measured. Mutation-checked by restoring `sorted[0]`, which fails five of them. Four cache keys move: bench-unfiltered-v127, all-benchmarks-v120, bench-filters-v65 and providers-v34. The last one is the point: the index feeds the chip, so a cached one keeps claiming the rank for its whole 900 s TTL. Rebased onto the v33 another session landed while this was being written. Stacked on #3424, which fixes the same audit's other two findings. 260 specs valid, tsc clean, 838 tests pass. * a floor we reached was printed as a limit they set, and a handshake was inside the measurement The audit's last two findings. Both are measurements that needed rebuilding rather than numbers that needed clamping, which is why they were held back from the blocker pass. THE LADDER DID NOT SAY WHAT ITS NUMBER MEANT. `climb` keeps the last accepted rung when one of OUR calls fails above it, and publishes it the same way it publishes a provider's refusal. Live, from the audit: Quicknode reads 10,000 on seven chains after an HTTP error at the 100,000 rung, and GetBlock 1,000 on Arc after one at 2,000. Both render as the provider's guard. Either may be. Nothing in the figure says we never asked higher. The gauge now carries a `bound` label with three values, and they are not interchangeable: refused the provider declined the next rung. The figure is its guard. failed our own call failed above it. The figure is a floor we reached. top every rung passed. The guard is above the ladder. The two window columns select `bound=~"refused|top"`, so a floor from our own failure leaves the cell blank instead of claiming a limit, and the reading stays in Prometheus for whoever is debugging. The pass line says which case it was, including the floor, so the next person reads it from the log rather than rediscovering it from a board. A rate-limit reply also stops counting as a width refusal. It says we asked too often, not that the window is too wide, and reading it as a limit publishes our own cadence as their policy. Same rule that already refuses to classify a timeout. The match list is deliberately narrow: anything unrecognised stays a width refusal, because that is the common case and widening it would erase true measurements. THE WORK TERM HAD A HANDSHAKE INSIDE IT. I wrote that the two eth_call legs share one cold connection. They do not: coldTransport sets DisableKeepAlives, so each leg dialled its own and paid its own DNS, TCP and TLS. A handshake is about 25 ms from this container and the difference being measured is a few milliseconds, so the noise was larger than the signal and it crossed zero in both directions. The sign guard from #3420 removes only the half below zero; the audit found GetBlock at plus 0.568 ms on Ethereum, which would sort first on a lower-is-better view for exactly the reason a negative would. So both legs are primed now. `coverageProbe` gains a `warm` field, off for every capability question, where the socket cannot change the answer and a prime would double the spend for nothing, and on for the pair, where the handshake is the thing in the way. The measured call then rides a pooled connection and the handshake is paid outside it. Cost: one unmeasured call per leg per pass. On the hourly lane that is 1,440 requests a month per endpoint, against the smallest budget in the cohort of 300,000. Nine tests, carrying the production messages as they were read. Mutation checked three ways: removing the throttle rule fails the throttle test, dropping the failed bound fails the bound test, and the earlier sign-guard tests still hold. Cache keys move in lockstep, v128 / v121 / v66. 260 specs valid, tsc clean, 838 site tests, go build, go vet and go test clean. * the throttle needle "429" also matches a block number Caught re-reading my own fix from an hour ago, before the audit could. acceptedSpan never sees the HTTP status: probe.go discards a non-200 body, so only the JSON-RPC message reaches it. Matching "429" as a substring there does not find a throttle, it finds three digits. Both of these are width refusals, which is the measurement this ladder exists to take: eth_getLogs range of 4291 blocks exceeds the 2000-block limit query returned more than 10000 results from block 14290000 Either would have been read as our problem rather than their policy, made the rung non-definitive, and dropped a true reading. The failure is silent: a provider simply stops publishing a window and nothing says why. The spelled-out forms cover a real throttle without that risk, so the bare digits are gone. Two tests now carry messages whose width or block number contains 429, and a mutation that puts the needle back fails them. This is the same shape as a case-sensitive needle reading a page as empty earlier today: a matcher that catches more than it names. go build, go vet, go test clean.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
four readings a day cannot say whether the work term ranks anyone
The heavy eth_call and its light reference have been probed since #3407, on
the capability cadence of once every six hours. That cadence is right for the
question it was built for: whether a provider routes a method is a property of
a plan and changes monthly. It is wrong for a measurement, and the work term
is a measurement.
Asked directly, on eleven keyed cells from a laptop, three repeats each:
That is a 48 ms spread between providers against 109 ms of dispersion inside
the measuring instrument, so from that vantage the honest answer is that it
does not rank anything yet. The deltas are nevertheless suggestive in a way
worth chasing: Arc, a young low-traffic chain, costs a fifth of what Ethereum
costs for the same fifty state reads, which is exactly the "depends on hardware
capacity" effect the review was pointing at.
Whether the spread survives from a datacentre is a question about sample count,
and sample count is the one variable a cadence controls. At four readings a day
a week yields 28 points per cell. Hourly yields 168.
WHAT THIS DELIBERATELY DOES NOT DO is raise the whole pass. Twelve probes
hourly would cost a provider with eight EVM cells about 69,000 requests a month
in this region, 19% of Infura's 370,000 budget on top of the 173,000 the tip
probe already spends there. Two probes cost 11,520 for the same footprint,
about 3%. The instruction that came with this was to watch the plans, and that
is what watching them looks like: raise the cadence of the thing being
measured, not of the thing that changes monthly.
Same region as the capability pass, because a difference between two legs is
the work only if both legs share a vantage point. Offset four minutes from it
so the two never interleave on one endpoint, which would put a capability probe
between the legs. Only a PAIR counts: a heavy reading whose light partner
failed has no reference to be a difference from, and the pass line says how
many endpoints produced one, so the lane's own yield is visible rather than
assumed.
Both legs are built through the same constructor the capability pass uses, so
the verdict rule and the latency rule cannot drift between the two cadences; a
test asserts it, because a delta computed across two definitions of "served" is
not a delta.
The cadence is tunable from Railway without a rebuild and floored at five
minutes. Below that this stops measuring the provider and starts measuring what
happens when we hammer it, which is both dishonest and a good way to lose a
key. Mutation-checked by removing the floor.
Nothing is published. This changes how often a number is taken, not whether it
reaches a page. The bench this is heading for is a judgment that needs a week
of real samples first, and those samples now arrive six times faster.
Three tests. go build, go vet, go test clean.