Validating MAXIMUM_GOSSIP_CLOCK_DISPARITY

[jrhea]

The phase 0 networking spec declares a constant MAXIMUM_GOSSIP_CLOCK_DISPARITY and sets it to 500ms. The design rationale portion of the networking spec mentions that 500ms is currently a placeholder and will be tuned based on testnet observations. How do we plan on validating this constant?

IIRC, @arnetheduck mentioned needing to lower the value (making it more negative) in order to improve performance, but provided the disclaimer that it was based on anecdotal evidence.

In my limited observation, I haven't seen any blocks arriving sooner than 500 milliseconds prior to the slot. Below is a plot from my post on block propagation analysis:

This plot was generated from 23,910 slots worth of blocks received. It should be noted that the network agent that collected the data does not filter out blocks arriving too soon. You can see that all blocks are within the MAXIMUM_GOSSIP_CLOCK_DISPARITY; however, this just reflects machine's view of time relative to the peers sending the block.

Does anyone have an intuition on how this constant should be validated? @ericsson49 might have some insight given his work on clock sync methodologies.

[jrhea]

I imagine that the methodology used for synchronizing clocks will have some part in deciding the appropriate value for MAXIMUM_GOSSIP_CLOCK_DISPARITY and this discussion could easily spiral into discussion methods for dealing with time drift. As a result, I suggest that we limit the scope of this debate by assuming Phase 0 will rely solely on NTP. Perhaps this will provide some reasonable starting point when speculating about resolution, slewing, etc and allow us to focus more on how this constant could impact consensus (we can always circle back this when things change).