Eager dlinear reporting consensus duration greater than legacy inc timer

[dB2510]

🎯 Problem to be solved

eager_dlinear timer is reporting consensus duration metric greater than legacy increasing time. The eager_dlinear starts measuring duration BEFORE it can propose so the duration of eager timers start before normal times. How do we compare the duration of eager timers vs normal timers, since they do not measure the same thing?

🛠️ Proposed solution

There are some ways to approach this:

• Consensus delay from start of slot (or start of duty offset) is probably best. But that includes fetcher delay, so the data wouldn't be focussed on consensus only, so biased by beacon node score. At least the bias introduced should be uncorrelated to timer type.
• Other option:
  • Duration from consensus propose (post fetcher) to consensus decide
  • This could however result in negative values for eager timers, but that is probably fine.
  • This would at least focus on consensus only.
  • duration=consensus_decided_at-consensus_proposed_at

🧪 Tests

• Tested by new automated unit/integration/smoke tests
• Manually tested on core team/canary/test clusters
• Manually tested on local compose simnet

[OisinKyne]

What is the root problem here? Is our QBFT experiment borked because of this bug?