Measuring Asymmetric latency via NTP, part 3

Part 1, Part 2

Varying round trip times

Asymmetric latency changes NTP's calculated clock offsets. What do the offsets look like when two clocks are in sync (or always within ~200us) and the latency varies?

SMQ clock, request through upstream

First image, clock smq (GPS-based NTP server) offset vs round trip time as measured by the local GPS clock. The request goes through the cable modem upstream, and the response goes through the cable modem downstream. The red crosses are individual NTP measurements. The green line is the estimation $offset = 1/2 * $rtt - 29300.

Roughly speaking, a +10ms change in latency shows up as a +5ms change in offset.

LON clock, request through upstream

Second image, clock lon (another GPS-based NTP server) offset vs round trip time as measured by the local GPS clock. The green line is the estimation $offset = 1/2 * $rtt - 62000.

This graph has the same shape as the SMQ clock.

local GPS clock, response through upstream

Third image, the local GPS NTP server's offset vs round trip time as measured by a VM on the other side of the cable modem. The slope of the line is in the opposite direction. The green line is the estimation $offset = -1/2 * $rtt + 4600.

Explanation

We start with the previous equation: $offset = $time_remote - $rtt/2 - $time_local. If the clocks are in sync, and we're measuring based on the request timestamps, $time_remote = $time_local + $request_latency. Combine that with $rtt = $request_latency + $response_latency, a positive change in $request_latency while $response_latency stays constant, yields a positive change in $offset by 1/2 the amount. In the other direction, a positive change in $response_latency will result in a negative change in $offset by 1/2 the amount. The graphs match the expectations, and show the majority of changes in latency are through the cable modem upstream.