Scenario
Round-trip latencies for chained requests eth_getBlockByNumber(latest, false) and eth_getLogs(hash) with start-to-start throttling of (at least) 1100 ms for every request.
Also, block number consistency with block availability and block age. The block propagation comparison is conservative and latency-agnostic.
Of the possible 31 regions, 2 were selected for data collection: Montreal and Milan.
Each location probe breaks its processing loop if / when the endpoint response is too-many-requests, a.k.a. HTTP code 429 etc. Also, codes 401 and 403.
At the time of the report generation: 4 of 4 datasets were available from 2 selected regions x 2 endpoints.
Additional info about RPC Inspector Pro technology is in the FAQ and documentation
Findings
| Endpoint | Lagging | Unique | Lowest | Arrival Tms | Arrival Region | Highest | Arrival Tms | Arrival Region |
|---|---|---|---|---|---|---|---|---|
| A. tron-evm.Publicnode.com | 0 | 11 | 82,727,262 | 1,778,850,218,350 | Milan / AWS | 82,727,272 | 1,778,850,246,987 | Milan / AWS |
| B. tron.api.Pocket.network | 1 | 11 | 82,727,262 | 1,778,850,218,480 | Milan / AWS | 82,727,272 | 1,778,850,247,154 | Milan / AWS |
We detected 1 response whose sendTms, arrivalTms and number was such that we can state the endpoint was lagging in the respective region.
E.g. on arrivalTms=1,778,850,229,799 in Montreal / AWS, we received number 82,727,266 from A. tron-evm.Publicnode.com. Afterwards, on sendTms=1,778,850,231,533 we dispatched a request to B. tron.api.Pocket.network, which returned lower number 82,727,265 at arrivalTms=1,778,850,231,810. Therefore, B. tron.api.Pocket.network was lagging because it was returning lower number 82,727,265 well after A. tron-evm.Publicnode.com advanced to 82,727,266.
Details
Latencies exclude one warmup request per endpoint in each region. Additional columns are visible when you scroll to the right.