Re: [codec] #22: Memory Usage?
"codec issue tracker" <trac@tools.ietf.org> Sat, 01 May 2010 14:12 UTC
Return-Path: <trac@tools.ietf.org>
X-Original-To: codec@core3.amsl.com
Delivered-To: codec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD53C3A6A6B for <codec@core3.amsl.com>; Sat, 1 May 2010 07:12:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.203
X-Spam-Level:
X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[AWL=-1.203, BAYES_50=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P+yKqBiXh8si for <codec@core3.amsl.com>; Sat, 1 May 2010 07:12:08 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id F10493A6B9A for <codec@ietf.org>; Sat, 1 May 2010 07:10:59 -0700 (PDT)
Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from <trac@tools.ietf.org>) id 1O8DP3-0003zv-60; Sat, 01 May 2010 07:10:45 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: codec issue tracker <trac@tools.ietf.org>
X-Trac-Version: 0.11.6
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.11.6, by Edgewall Software
To: hoene@uni-tuebingen.de
X-Trac-Project: codec
Date: Sat, 01 May 2010 14:10:45 -0000
X-URL: http://tools.ietf.org/codec/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/22#comment:1
Message-ID: <071.6815a304f033a6107bf10a7f7d821839@tools.ietf.org>
References: <062.50559ef09aa4fd48fa3d3f5ca56fbf1b@tools.ietf.org>
X-Trac-Ticket-ID: 22
In-Reply-To: <062.50559ef09aa4fd48fa3d3f5ca56fbf1b@tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: hoene@uni-tuebingen.de, codec@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Cc: codec@ietf.org
Subject: Re: [codec] #22: Memory Usage?
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.9
Reply-To: codec@ietf.org
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 01 May 2010 14:12:09 -0000
#22: Memory Usage? ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: defect | Status: new Priority: major | Milestone: Component: requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- Comment(by hoene@…): [Raymond]: (IPend-to-transcoding_gateway-to-PSTNend), the transcoding gateway, or VoIP gateway, often has to encode and decode thousands of voice channels in a single box, so not only the computational complexity, but also the per-instance RAM size requirement of the codec become very important for achieving high channel density in the gateway. [JM]: Agreed here, although I would say that per-instance RAM -- as long as it's reasonable -- is probably a bit less important than complexity. [Raymond]: per-instance RAM is definitely not unimportant. I have worked in a team that designed high-density VoIP gateways, and I know people did all kinds of tricks to reduce the RAM usage as much as possible because of the high cost of the external high-speed SRAM used by high-speed DSPs in such gateways. Currently, high-density VoIP gateways can have several tens of thousands of voice channels per box or per equipment rack. If codec A uses X kbytes more per-instance RAM than codec B, than implementing codec A rather than codec B in all channels will require X * (number of channels) more kbytes of high-speed SRAM, which can be a substantial additional cost. Similarly, if codec A requires a substantially higher DSP MHz than codec B, then implementing codec A in all channels will mean that more high- speed DSP chips need to be used to maintain the same number of channels. That's additional cost. Actually, the more likely scenario is that the number of DSP chips has already maxed out due to board space or heat dissipation constraint, then the gateway can only support a substantially smaller number of voice channels when compared with using codec B. Consequently, the channel density per box or per rack goes down substantially, and the per-channel deployment cost goes up substantially. Thus, even if implementing codec A or codec B makes no practical difference in a PC, it can make a very real and substantial cost difference in VoIP gateways. -- Ticket URL: <http://trac.tools.ietf.org/wg/codec/trac/ticket/22#comment:1> codec <http://tools.ietf.org/codec/>
- [codec] #22: Memory Usage? codec issue tracker
- Re: [codec] #22: Memory Usage? codec issue tracker
- Re: [codec] requirements #22 (closed): Memory Usa… codec issue tracker