Re: [codec] #16: Multicast?

["Raymond (Juin-Hwey) Chen" <[e-mail]>]

Hi Koen,

I too don't want to see this discussion drags on, but some of your comments 
seem misleading to me, so I would like to respond with some quick comments. 

Wideband is a new feature in some devices and is a check box that a product 
manager needs to check off to remain competitive.  That doesn't mean 
wideband is more important than existing features in a device.  Also, I 
am not sure the cost difference is a few dimes versus several dollars. In 
some devices the extra cost of adding wideband is minimal. Furthermore, it 
is not only a cost issue but also a power consumption issue.  No one in his 
or her right mind will use a processor that's 5X to 10X faster than 
necessary just in order to reduce the encoder and decoder RTS delays to a 
small fraction of the codec frame size; this is just the way it is and has 
nothing to do with the relative importance of delay or anything else.  

You were presenting it as if this were a reasonable choice that device 
designers could easily make but chose not to make, but that's just not 
true.  It has always been the case that the designers will use processors 
just fast enough for the job, perhaps with a little margin for the 
unexpected, but not 5X or 10X.  Given this, the bottom line is that ~ 3X 
codec frame size is the "norm" or a "necessary result" for special-purpose 
hardware devices rather than by a design choice, and you are just lucky to 
get < 2X in PC-based VoIP calls because PCs were not designed for voice 
calls but for other much more computationally demanding tasks.  (Even there 
you can't guarantee that PCs will always give you a multiplier of < 2X.  
What if the PC is heavily loaded with other tasks?  Then you are more likely
to get 3X if you don't want your voice stream to run out of real time.)

Best Regards,

Raymond

-----Original Message-----
From: Koen Vos [mailto:[e-mail]] 
Sent: Wednesday, May 26, 2010 9:43 PM
To: Raymond (Juin-Hwey) Chen
Cc: [e-mail]
Subject: RE: [codec] #16: Multicast?

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
>
>
>