[Bloat] DSLReports Speed Test has latency measurement built-in

Sebastian Moeller moeller0 at gmx.de
Thu May 7 02:19:48 EDT 2015


Hi Jonathan,


On May 6, 2015, at 22:25 , Jonathan Morton <chromatix99 at gmail.com> wrote:

> So, as a proposed methodology, how does this sound:
> 
> Determine a reasonable ballpark figure for typical codec and jitter-buffer delay (one way). Fix this as a constant value for the benchmark.

	But we can do better, assuming captive de-jitter buffers (and they better are), we can take the induced latency per direction as first approximation of the required de-jitter buffer size.

> 
> Measure the baseline network delays (round trip) to various reference points worldwide.
> 
> Measure the maximum induced delays in each direction.
> 
> For each reference point, sum two sets of constant delays, the baseline network delay, and both directions' induced delays.

	I think we should not count the de-jitter buffer and the actually PDV twice, as far as I understand the principle of the de-jittering is to introduce a buffer deep enough to smooth out the real variable packet latency, so at best we should count max(induced latency per direction, de-jitter buffer depth per direction), so the induced latency (or a suitable high percentile if we aim for good enough instead of perfect) is the best estimator we have for the jitter-induced delay. But this is not my line of work so I could b out to lunch here...


> 
> Compare these totals to twice the ITU benchmark figures, rate accordingly, and plot on a map.

	I like the map idea (and I think I have seen something like this recently, I think visualizing propagation speed in fiber). Now any map just based on actual distance on the earth’s surface is going to give a lower bound, but that should still be a decent estimate (unless something nefarious like http://research.dyn.com/2013/11/mitm-internet-hijacking/ is going on then all bets are off ;) )

Best Regards
	Sebastian

> 
> - Jonathan Morton




More information about the Bloat mailing list