We polled 22 net2040 nodes on three hosts for five minutes and recorded when each node first reported a new head. On the lightly loaded hosts, the fork clients and geth-XDC reported a block about 0.4 s after its timestamp (median), and the xOneRS nodes about 0.7 to 1.0 s after it. On the busy build host, the xOne nodes had medians from 0.8 to 3.7 s and long tails. This is one short sample, not a benchmark: the host load differs a lot, and the clock and timestamp limits below are as large as some of the gaps.

For the size, memory and RPC comparison of the same fleet, see the fleet snapshot.

How was it measured?

Read-only, on 2026-11-15 between about 03:11 and 03:16 UTC (block timestamps of the window), by the xOne team on its own follower nodes:

  • On each host, one thread per node called eth_blockNumber on the node's local RPC every 0.25 s for 300 s, and kept the wall-clock time at which each new head number was first seen.
  • The block timestamps came from one xOneRS archive node. The window covered blocks 847,716 to 847,789 (74 blocks).
  • Arrival = first-seen time minus block timestamp. The first head of each node is left out, because it was already there when polling started.
  • All three hosts reported NTPSynchronized=yes.

What did each node show?

Load averages at the end of the run (1 minute): host A 37.89, host B 1.74, host C 20.77. Host A is the 20-core host that also runs builds; its load is the subject of four clients on one host.

REFERENCE TABLEScroll to explore all columns →
Host Node Blocks timed p50 (s) p90 (s) max (s)
B geth-XDC full (reference) 70 0.40 0.97 1.21
B reth-xdc archive 70 0.38 0.91 1.36
B besu-xdc full (Bonsai) 70 0.45 1.01 1.27
B nethermind-xdc (three nodes) 69-70 0.44-0.46 0.97-1.01 1.24-1.29
B xOneRS full 64 0.68 1.52 3.59
C nethermind-xdc full (hybrid) 69 0.38 0.96 1.35
C nethermind-xdc archive 70 0.40 1.04 1.34
C reth-xdc full 68 0.41 0.99 1.26
C besu-xdc snap (Bonsai) 23 0.90 1.30 4.65
C xOneRS minimal 64 0.78 2.17 3.96
C xOneRS fast 63 0.96 1.78 4.57
A xOneRS archive 65 0.95 2.90 5.83
A xOneRS full 66 1.04 4.05 9.84
A xOneC (archive, full, minimal, snap) 56-65 0.78-1.23 1.67-4.85 7.30-9.56
A xOneTS full 61 1.76 3.97 8.73
A xOnePy minimal 29 1.18 6.64 21.45
A xOnePy snap 50 3.74 30.56 43.21

"Blocks timed" below 70 means the node reported several blocks at once, so some block numbers were never its head when polled.

How should these numbers be read?

  • Same host, different client. On host B, geth-XDC reported at a 0.40 s median and the xOneRS full node at 0.68 s. On host C, reth-xdc and nethermind-xdc reported at about 0.4 s and the two xOneRS nodes at 0.78 and 0.96 s. These are the fairest comparisons in the sample, and they put xOneRS later by a few tenths of a second at the median.
  • Host load. Every TypeScript, Python and C++ node in the sample ran on host A, at a load average near 38 on 20 cores. Their numbers mix the client with the host, so they do not rank the clients.
  • Limits of the method. Block timestamps have a resolution of one second, and polling adds up to 0.25 s. Two reth-xdc readings came out negative (as low as -1.58 s), which shows the size of the timestamp and clock error.

What does this sample not show?

  • Why a node reports a head later. The node may receive the block later, or receive it on time and expose the new head only after it executes and commits the block. The sample cannot tell these apart.
  • Anything about block production or seal timing.
  • More than one five-minute window. A longer, repeated series on hosts with equal load is the next step.

The collected competitor articles state no block-arrival numbers, so this post has no comparison table with their claims.

Frequently asked questions

How long after its timestamp does a net2040 block reach a node?

In this sample, about 0.4 s at the median for geth-XDC and the fork clients on lightly loaded hosts, and about 0.7 to 1.0 s for the xOneRS nodes on the same hosts.

Why are the TypeScript and Python numbers so much higher?

All of those nodes ran on the busiest host, at a load average near 38 on 20 cores. The sample does not separate the effect of the host from the effect of the client.

Are the host clocks in sync?

Each host reported NTPSynchronized=yes. Block timestamps still have a one-second resolution, so differences below about one second are within the error.

Where are the hosts?

The post names them A, B and C only. The sample does not depend on where they are.

Sources