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

[Sebastian Moeller]

Hi Mikael,


On Apr 28, 2015, at 14:24 , Mikael Abrahamsson <swmike at swm.pp.se> wrote:

> On Tue, 28 Apr 2015, Sebastian Moeller wrote:
> 
>> 	From "Table 4.1 Delay Specifications” of that link we basically have a recapitulation of the ITU-T G.114 source, one-way mouth to ear latency thresholds for acceptable voip performance. The rest of the link discusses additional sources of latency and should allow to come up with a reasonable estimate how much of the latency budget can be spend on the transit. So in my mind an decent thresholds would be (150ms mouth-to-ear-delay - sender-processing - receiver-processing) * 2. Then again I think the discussion turned to relating buffer-bloat inured latency as jitter source, so the thresholds should be framed in a jitter-budget, not pure latency ;).
> 
> Yes, it's all about mouth-to-ear and then back again. I have historically been involved a few times in analyzing end-to-end latency when customer complaints came in about delay, it seemed that customers started complaining around 450-550 ms RTT (mouth-network-ear-mouth-network-ear).

	Ah, this fits with the ITU figure 1 data, at ~250ms one-way delay they switch from “users very satisfied” to “users satisfied”, also showing that the ITU had very patient subjects in their tests… So if we need to allow for sampling and de-jittering at both ends costing say 50ms we end up with a threshold of acceptable total threshold of ~400ms network RTT for decent voip conversations. Actually lets assume the sender takes 30ms for sampling and packetizing, and the recover takes actual jointer ms for its dejittering filter/buffer, then we can draw the threshold as a function of maximum latency under load increase...
	Do you have numbers for acceptable jitter levels?

> 
> This usually was a result of multiple PDV (Packet Delay Variation, a.k.a jitter) buffers due media conversions on the voice path,

	This sucks.

> for instance when there was VoIP-TDM-VoIP-ATM-VoIP and potentially even more conversions due to VoIP/PSTN/Mobile interaction.

	I hope the future will cut this down to at max one transition, or preferably none ;) (with both PSTN and TDM slowly going the way of the Dodo).

Best Regards
	Sebastian

> 
> So this is one reason I am interested in the bufferbloat movement, because with less bufferbloat then one can get away with smaller PDV buffers, which means less end-to-end delay for realtime applications.
> 
> -- 
> Mikael Abrahamsson    email: swmike at swm.pp.se