To get this topic a little more tangible I took a look at the Epoch 303 Stats from PoolTool.
Please note that not all of the data is 100% representative as pools with a low number of blocks could suffer from low sample data.
Propagation Time Analysis
PoolTool is collecting Data about Propagation Latencies. The data is collected from nodes that are reporting Data to Pooltool. It shows data from a receiver and a producer perspective.
Producer Data is available for all Pools which at least minted one block. This also includes pools that are not reporting data itself because the according numbers are collected from the pools which are receiving this block.
Receiver Data is only available for Pools that report Data themselves.
For our analysis, we took a look at the Producer Data because this is simply available for moor pools. Please consider that data for small pools is getting less accurate because of the low sample number. On the other hand, the results of pools that are generating a low number of blocks are also less important for the overall network health.
So let’s dig into the different observations:
#1 Propagation times outside a ± 5 s window
There is a total average of 9.5% of reported propagation times which is >5s. This means that the time when some receiving pool (which reports to PoolTool) is getting the block the time is either >5s after the scheduled slot is >5s still in the future.
It’s not plausible that a propagation really takes longer than 5s as the average currently is ~750ms. So the most probable assumption is that some of the receiving pools are either far off time or reporting invalid data to PoolTool.
#1a Pools with an above-average percentage of times outside a ±5 s window
The average of delays outside ±5s is 9.5%. For some pools, this metric is extraordinarily high. I set a tolerance of 10.5% on this report with the following results:
Why those pools are showing higher numbers is unclear. I don’t see a specific reason why for some blocks the number should be much higher than for others. Therefore I assume that those pools are the ones that are partly causing the 9.5% of reported times for other pools.
#2 Blocks which are distributed before they even are scheduled
About 3% of the analyzed pools are distributing blocks ahead of time. This shows up as negative propagation times on PoolTool. The average across all pools is 0.2%. Please note that this early reception also can be caused by a wrong time on the receiver that’s why we set a 1% threshold as acceptable for this measure. Concretely the 3% include all pools where the data shows at least 1% negative times excluding the times which are below -5s
The only logical reason for this phenomenon is misconfigured time on that 3% of the pools which are running ahead of time.
#3 Pools with high average propagation times
The example above shows a pool with high average propagation times. The global average is ~750 ms. The analyzed data shows the following distribution of average times:
1689 pools (which were not filtered out above by anomalies)
491 (29.1%) < 500 avg
916 (54.2%) < 1000 avg
184 (10.9%) < 1500 avg
98 ( 5.8%)>= 1500 avg
Bad average times can be caused by a low number of IN connections, which cause additional hops until the block distributes across all nodes. It could also be caused by poor internet connections, e.g. for home-operated nodes.
On the other hand, it also can be caused by using a hosting location that is not optimally connected to the rest of the world. This by the way is not really a bad thing as decentralization also implies distributing nodes worldwide. Anyways considerations like accelerated network connections could help in such scenarios.