Re: [codec] #16: Multicast?

Koen Vos <> Thu, 27 May 2010 04:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0AE953A677D for <>; Wed, 26 May 2010 21:43:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.65
X-Spam-Level: *
X-Spam-Status: No, score=1.65 tagged_above=-999 required=5 tests=[AWL=1.649, BAYES_50=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BpIlsm0orXhU for <>; Wed, 26 May 2010 21:43:07 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CEFEB3A680F for <>; Wed, 26 May 2010 21:43:06 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 075892006D5CE; Thu, 27 May 2010 06:42:57 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=message-id :date:from:to:cc:subject:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mail; bh=5mxlDc30daVA HMOJdHLngkFyKzM=; b=a+z4g+M00V5nEB+MmSmaNTJv9UxQc/mtQhbbaQO4R+u0 CXPrja8TZoM1141WWsQDnbCtDAqCBNWURkqRBf9s9GZv6erCgs7pJyVxKENb1ENG E/2GRQVxw3ANbKzLToRW4jh2HnCDsm+ops8piRrMLT6ptTeJCCGz+ll4Pj6QgJg=
DomainKey-Signature: a=rsa-sha1; c=nofws;; h=message-id:date:from :to:cc:subject:references:in-reply-to:mime-version:content-type: content-transfer-encoding; q=dns; s=mail; b=RHwMe/kgnMI8T7cTaYFq R+vsrQkfRBS3Fzij5S3YWIhqWEgoCedz7Esl7RQIMx6ubDx/4aSCsUfUm5GBypvQ ImL1zod2mwMJvNuN/ELL933y9usNRVNeMDVt6Lh0BqK/dIM4vnP3UsCOUYD0cieM ivHIem+Yqc/NuJZbEs8KPW0=
Received: from localhost (localhost []) by (Postfix) with ESMTP id 03CE32006D5CA; Thu, 27 May 2010 06:42:57 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ixRvxviF9lhj; Thu, 27 May 2010 06:42:55 +0200 (CEST)
Received: by (Postfix, from userid 33) id 71BA12006D5CB; Thu, 27 May 2010 06:42:55 +0200 (CEST)
Received: from ( []) by (Horde Framework) with HTTP; Wed, 26 May 2010 21:42:55 -0700
Message-ID: <>
Date: Wed, 26 May 2010 21:42:55 -0700
From: Koen Vos <>
To: "Raymond (Juin-Hwey) Chen" <>
References: <> <> <> <> <> <000001cae173$dba012f0$92e038d0$@de> <> <001101cae177$e8aa6780$b9ff3680$@de> <> <002d01cae188$a330b2c0$e9921840$@de> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; DelSp="Yes"; format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
User-Agent: Internet Messaging Program (IMP) H3 (4.3.4)
Cc: "" <>
Subject: Re: [codec] #16: Multicast?
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Codec WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 27 May 2010 04:43:09 -0000

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.


> 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