Re: [codec] #16: Multicast?

If the frame-size multiplier is due to serialization, then I agree with
Koen's assessment.  In fact on many connections the multiplier would be less
than 1. Dial-up is of course the worst case here, and on those links the
multiplier ought to be close to 2.  Variations due to congestion (and on
some links, polling) are (IMHO) better modeled as jitter.

Gateways are another matter, with the delays being highly dependent on the
product architecture.  Interupt latencies, context switching, bus
architectures, etc. can dominate, so it is totally possible that reducing
the frame size might actually increase the latency (since it increases the
packets per second load on the gateway).  So I agree with Koen on this as
well.

Anecdotal models based on industry experience can be useful guides - though
if we are going to use these models to drive requirements, I'd prefer
something more analytical.

Stephen Botzko

On Sat, May 1, 2010 at 2:07 AM, Koen Vos <koen.vos@skype.net> wrote:

> Quoting "Raymond (Juin-Hwey) Chen":
>
>   One-way delay = codec-independent delay + 3*(codec frame size) + (codec
>> look-ahead) + (codec filtering delay if any)
>>
>> This formula was obtained from an experienced engineer who has been
>> working on IP phones related fields for more than a decade,
>>
>
> At Skype We have 100+ years of combined VoIP experience, and a focus on
> minimizing delay as part of our goal to maximize quality.  The consensus
> among our engineers is that the multiplier is closer to 1 than to 2, at
> least for software VoIP applications over typical Internet connections.
>  Some years ago the situation was slightly worse because dial-up was more
> prevalent.
>
>
>
>  Similar 3X multiplier is also observed in VoIP gateways.  Even with a fast
>> processor/system optimized from ground up to be low-delay, the measured
>> "codec-dependent" one-way delay of such a VoIP gateway using the G.711 codec
>> with a 5 ms frame/packet size is between 12 and 17 ms, or around 3X the
>> frame size.
>>
>
> As I've pointed out before, that doesn't say much about how the delay
> increases with larger frame sizes.  Perhaps the 12~17 ms includes a constant
> delay of 7 ms, and the marginal growth of delay with frame size is 1x.
>
> best,
> koen.
>
> _______________________________________________
> codec mailing list
> codec@ietf.org
> https://www.ietf.org/mailman/listinfo/codec
>