One of the key behaviour of a coordinated omission free load generator is to always consider as start time the so-called "intended" one, in order to properly account for coordination omission.
If this finding is correct we should store the intended start time in the session and copying to the Request in order to use it to update the statistics accounting for "infrastructure" coordination issues.
Furthermore we could track any skew as blocking time (within the infrastructure) as soon as it is copied into it, to make it more clear while presenting the latency charts.
One of the key behaviour of a coordinated omission free load generator is to always consider as start time the so-called "intended" one, in order to properly account for coordination omission.
https://github.com/Hyperfoil/Hyperfoil/blob/643568bc7731d381ea71d95ec929bc39046e2d3c/api/src/main/java/io/hyperfoil/api/connection/Request.java#L132 shows that the statistics are using the request's start time, obtained at https://github.com/Hyperfoil/Hyperfoil/blob/643568bc7731d381ea71d95ec929bc39046e2d3c/api/src/main/java/io/hyperfoil/api/connection/Request.java#L63 which is not the value computed by the phase instance's rate generators and, depending what happen in-between, can be distant from it.
If this finding is correct we should store the intended start time in the session and copying to the Request in order to use it to update the statistics accounting for "infrastructure" coordination issues. Furthermore we could track any skew as blocking time (within the infrastructure) as soon as it is copied into it, to make it more clear while presenting the latency charts.