At the moment we ask the orchestrator for its NTP time, and we report the difference between "orchestrator time" and "local machine time", and the uncertainty interval of that difference.
This uncertainty interval is simply the local machine time when we received the orchestrator reply and the local machine time when we sent the request, so we now for sure that the reported orchestrator time was sampled somewhere within that interval.
We do not use the orchestrator NTP time for anything anymore. In fact, we immediately forget it as soon as we've printed the numbers above.
In one sense this is good: if all machines have a decent NTP clock synchronisation this means that things like reported latency are not dependent on the orchestrator time uncertainty interval, which is always going to be larger than the RTT (round trip time) between the local machine and the orchestrator, and which should be much larger than the desynchronisation of well-behaved NTP clocks.
But VRTstatistics converts all timestamps to "session time", which it defines as the expected orchestrator time, which it defines as the half-way point on the uncertainty interval.
If the network latency between the orchestrator and the client is symmetric that is a good guess. But if it is asymmetric it is a bad idea, and this may be what happens with traffic-shaping induced latency.
At the moment we ask the orchestrator for its NTP time, and we report the difference between "orchestrator time" and "local machine time", and the uncertainty interval of that difference.
This uncertainty interval is simply the local machine time when we received the orchestrator reply and the local machine time when we sent the request, so we now for sure that the reported orchestrator time was sampled somewhere within that interval.
We do not use the orchestrator NTP time for anything anymore. In fact, we immediately forget it as soon as we've printed the numbers above.
In one sense this is good: if all machines have a decent NTP clock synchronisation this means that things like reported latency are not dependent on the orchestrator time uncertainty interval, which is always going to be larger than the RTT (round trip time) between the local machine and the orchestrator, and which should be much larger than the desynchronisation of well-behaved NTP clocks.
But
VRTstatisticsconverts all timestamps to "session time", which it defines as the expected orchestrator time, which it defines as the half-way point on the uncertainty interval.If the network latency between the orchestrator and the client is symmetric that is a good guess. But if it is asymmetric it is a bad idea, and this may be what happens with traffic-shaping induced latency.