Why ec delay multiplier must be non-zero?

[masih]

It is unclear why this condition exists. Looking at the code, zero can also be a valid value. No?

go-f3/manifest/manifest.go

Line 172 in d4f080d

return fmt.Errorf("EC delay multiplier must positive, was %f", e.DelayMultiplier)

[Stebalien]

If that's zero,

go-f3/host.go

Line 346 in 9c8c852

ecDelay := time.Duration(h.manifest.EC.DelayMultiplier * float64(h.manifest.EC.Period))

becomes zero.

Honestly, I think 1 is the sane minimum in general. Unless I'm missing something.

[masih]

This ticket was captured as part of running a passive testing that was attempting to minimise the wait time between instances. Specifically to get ecDelay to indeed be zero. Because, we will always wait for HeadLookback number of epochs anyway.

My question remains: Why ecDelay of zero is invalid?

In terms of importance, maybe this does not matter anymore. Or at least it will not matter once transport is made more efficient such that the actual delta is a value closer to the default of 3 seconds.

[Kubuxu]

If we are in a caught-up regime, if ECDelay is zero, we will start a new instance before new tipsets become available. Plus, base decision behaviour depends on ECDelay being non-zero.

[masih]

we will start a new instance before new tipsets become available

Why? Headlookback should avoid this already?

[Kubuxu]

It doesn't headlookback just compensates from headlookback, not for tipsets that get created during the instance.

[masih]

Right, but we take the max of 0 and len-headlookback when collecting chain. If we are too close to the head then, would that not end up delaying the instance anyway? i.e. collecting base as the chain which would eventually back off from the start of next instance?

[Kubuxu]

It will be missing one or two epochs, I think two.