Re: [codec] #19: How large is the frame size depended delay / the serialization delay?

[stephen botzko <[e-mail]>]

>>>
Having said this, I would anyhow suggest to include the processing delay
into the measurement of the end-to-end (acoustic round) trip time.  Those
measurements should be part of the control loop that optimizes the overall
conversation call quality.
>>>

Hi Christian

I don't understand what you have in mind on this control loop idea, or what
the control loop has to do with acoustic round trip time.

Maybe you could outline your thoughts on this control loop generally in more
detail?

Stephen Botzko


On Sat, May 1, 2010 at 1:11 PM, Christian Hoene <[e-mail]>wrote:

>  Hi,
>
>
>
> I agree that serialization, processing, and implementation delay should be
> distinguished.
>
>
>
> Assume a low-cost VoIP phone with its processing power being fully utilized
> by one call: Then, the DSP/CPU needs an entire frame duration to encode and
> decode frames. Thus, the latency is increase by one frame length in addition
> to the serialization delay, propagation delay, algorithmic delay,
> dejittering delay, echo cancelling delay, ...  Running the chips at 100%
> load is of course cost saving compared to add some more computational
> resource. But is this still a relevant issue today?
>
>
>
> I am not sure whether it always make sense for mobile device to run at 100%
> load. Of course, from a energy consumption perceptive it make sense to run
> CMOS circuit at the lowest possible frequency as power consumption drops
> quadratic. But maybe running the CPU/DSP at higher speed and switching to
> power save mode if after the a frame has been decoded/encoded is be equally
> energy efficient…
>
>
>
> Even if a gateways DSP is utilized fully, the processing delays must not be
> very large. For example, take a gateway serving 10000 calls and all
> CPUs/DSPs are at 100%. Then, the time needed for encoding/decoding should be
> frame duration/10000, if the encoding/decoding is well scheduled.
>
>
>
> Also, I do not think we shall consider implementation delay, which occurs
> due to suboptimal implementation. For example, some years ago we tested the
> RTT of two Linux softphones link directly together using G.711. It was
> 400ms. The implementation delay could be a good performance metric to
> differentiate two otherwise equal products. Also, the algorithmic processing
> delay might be subject to similar market optimization.
>
>
>
> Having said this, I would anyhow suggest to include the processing delay
> into the measurement of the end-to-end (acoustic round) trip time.  Those
> measurements should be part of the control loop that optimizes the overall
> conversation call quality.
>
>
>
> Christian
>
>
>
> ---------------------------------------------------------------
>
> Dr.-Ing. Christian Hoene
>
> Interactive Communication Systems (ICS), University of Tübingen
>
> Sand 13, 72076 Tübingen, Germany, Phone [phone]
> http://www.net.uni-tuebingen.de/
>
>
>
> *From**:* [e-mail] [mailto:[e-mail]] *On
> Behalf Of *stephen botzko
> *Sent:* Saturday, May 01, 2010 3:31 PM
> *To:* Koen Vos
> *Cc:* [e-mail]
> *Subject:* 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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/codec
>
>
>
> _______________________________________________
> codec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/codec
>
>