Re: [codec] #16: Multicast?

[Koen Vos <[e-mail]>]

Quoting "Raymond (Juin-Hwey) Chen":
> My point is that we should not expect that future IP phones or gateways
> will operate at a very low percentage point of the processor load just
> because Moore's Law can improve processor speed over time.

In other words, future manufacturers won't spend a few dimes on  
reducing delay, even though today they're happy to add several dollars  
to the price just to enable wideband?  That's a statement about the  
relative importance of delay.

For the discussion about transmission delay vs. frame size, see e.g.
http://www.ietf.org/mail-archive/web/codec/current/msg01477.html

koen.



> Hi Koen,
>
> In-line below...
>
> You wrote:
>> The essence, if I understand you correctly, is that there still exist
>> low-end platforms with barely enough processing power to run a VoIP
>> call.  If such platforms use a naive FIFO scheduler, they'll create up
>> to one frame of processing delay for encoder and decoder each, on top
>> of the frame of buffering delay.
>
> [Raymond]: It doesn't have to be low-end platforms.  I wouldn't consider
> high-density VoIP gateways "low-end".  What matters is whether the
> processor is heavily loaded (i.e. busy at a high percentage of time)
> with real-time tasks (and thus is just fast enough). I think this is
> true for typical implementations of IP phones and VoIP gateways.
>
> I also wouldn't use the term "a naïve FIFO scheduler" to describe the
> "run to completion" real-time scheduler that I talked about in my last
> email, because that term seems to imply that it is a very simple-minded
> and inferior approach used by an inexperienced person who doesn't know
> anything better.  My understanding from talking to the three senior
> technical leads of Broadcom is that the reality is when you have many
> real-time tasks that you need to handle concurrently, using a
> prioritized interrupt-driven scheduler is just way too complex and
> messy, and it doesn't even guarantee that you will get a lower delay if
> you do go through the trouble.  In contrast, the kind of "run to
> completion" real-time scheduler that I talked about is a more elegant
> solution as it simplifies the scheduling problem substantially and also
> allows you to have more efficient utilization of the processor.
>
> Other than these two points, your understanding of my main point is
> correct.
>
>> The good news is that Moore's law will continue to drive down the
>> fraction of platforms with such processing delay problems.
>
> [Raymond]: This may be true for PC but probably not true in general.
> PC is a general-purpose computing device that has to handle numerous
> possible tasks, and a voice phone call takes only a very small fraction
> of the worst-case computational power requirement of a PC.  In contrast,
> for special-purpose dedicated hardware devices such as IP phones or
> VoIP gateways, it would make no sense to use a processor that is many
> times faster than the worst-case computational power requirement.  For
> the sake of cost and power efficiency, the designers of such special-
> purpose devices will want to use a processor that's just slightly faster
> than required, because then they can use the cheapest and/or lowest
> power-consuming processor that's fast enough to get the job done.
> If they choose to use a processor much faster than is required, then
> competitors using processors just fast enough can have lower costs
> and power consumption and can take market share away from them.
>
> A case in point: after its first appearance several decades ago, 8-bit
> microprocessors are still widely used in many devices today despite the
> several orders of magnitude of speed improvement provided by Moore's
> Law, because those devices just don't need anything faster, so using
> anything faster would be a waste of money and power consumption.
>
> My point is that we should not expect that future IP phones or gateways
> will operate at a very low percentage point of the processor load just
> because Moore's Law can improve processor speed over time. Therefore,
> don't expect the 3X multiplier for codec frame size to go down much
> below where they are now.
>
> In fact, if in addition to a VoIP call, a PC is heavily loaded with a
> lot of other concurrent tasks, many of which may be real-time tasks
> (e.g. video, playing/burning CD/DVD, networking, etc.), then it will be
> difficult for the PC to have small encoding and decoding RTS delays (d2
> and d5 in my delay analysis).  In this case, the codec frame size
> multiplier will be closer to 3X than to 1X, unless you are willing to
> let the voice stream occasionally run out of real time and produce an
> audible glitch (which is not acceptable from the voice quality
> perspective).  If you agree with this and agree that a PC sometimes
> does get very heavily loaded, then if you don't want the voice stream
> to run out of real time, the worst-case codec-dependent delay for
> PC can still be around 3X the codec frame size.
>
>> I'm a bit surprised by your analysis of "packet transmission delay",
>> as it has little bearing on our multiplier (ie the change in delay as
>> a function of frame size). See old posts.
>
> [Raymond]: I am not sure I understand what you are saying.  You probably
> misunderstood the goal of my analysis. I mentioned in my last email that
> my delay analysis aimed to derive the lower and upper bounds of the
> codec-dependent one-way delay as functions of both the codec frame size
> AND the packet size.  That "packet transmission delay" does depend on
> the packet size, so it should be included.  Also, including it doesn't
> increase the lower bound of the delay (and the codec frame size
> multiplier there); it only affects the upper bound.
>
> Or, are you saying the "packet transmission delay" depends on the packet
> size, not the codec frame size, and therefore is not codec-dependent?
> Well, we know the packet size should be a positive integer multiple of
> the codec frame size.  Once the codec frame size is determined, there
> are only limited choices of packet sizes you can use, so in this sense
> the packet size does depend on the codec frame size.  Therefore, the
> "packet transmission delay" indirectly depends on the choice of the
> codec.
>
> Best Regards,
>
> Raymond
>
>
>