Re: IVR Capcity

In article <1122974151.993518.263390@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
Andrea Denaro <andrea.denaro@xxxxxxxxx> wrote:
>May you please explain to me better the design issues of point 2?

First off, in my original 'off the top of my head' numbers, I slipped a
decimal point. Aggregate throughput needed is 'merely' in the 5-10 gigabit
range, not terabits. This requires an OC192 circuit, "at least". probably
more like three 0C96 circuits. With a multiplexor/de-multiplexor to
interface to 10-15 separate gigabit-Ethernet 'local' network segments.

However, dealing with even that level of network traffic in a single general-
purpose computer, presents a number of challenges. if, for convenience, you
use 8gbit/sec, that equates to 1gBYTE/sec. To output data at that speed,
you have to be able to transfer it from main memory to the output device
at that speed. *AND* you have to get it into main memory from some form
of 'secondary' storage. that means you have to have 'internal' data transfer
speeds of _2_ gBytes/sec. Plus the requirement for moving the 'instructions'
for the CPU from memory to the CPU itself. It is not uncommon for the
volume of 'instructions' to be larger than the volume of 'data' being moved.

To get this kind of multi-gigabyte/second data rate, on internal data-paths
within the computer, you have to have 'average access to data' speeds that
are in the fractional-nanosecond range. Present-day memory technology misses
that level by roughly two orders of magnitude, for an individual memory access.
Thus, you have to use multi-byte 'wide' access. Modern high-end micro-
processors support _eight_byte_ wide memory access. some memory-systems use
cache buffering at that level, with 16- or 32-byte wide interfaces behind
the cache to physical memory. For this kind of an application, caching
of _data_ does *not* improve performance noticeably -- it affects only
reading from memory, _not_ the writing to the 'telephone interface'.

Fast SDRAM (DDR 3000) has a "cycle" time of 5ns. with AAD being triple
that (latency of 3 cycles) 8 bytes in 15 ns is only 1 byte/2 ns. And we
need 1 byte / 0.2 ns. This is a problem! <wry grin>

'Conventional' architectures can (albeit barely) keep up with the capacity
of a single gigaBIT interface. Your application is looking at gigaBYTE data
rates. You don't get that in a single system, using 'commodity' hardware.

When you leave the realm of 'commodity' hardware, the cost for specialized
systems goes up precipitously.


Note the above calculations do _not_ consider the problems that arise when
multiple calls need access to the same data _at_the_same_time_ -- e.g.
playing the same menu selection to several users, simultaneously. Dealing
with _that_ issue requires 'faster' access to data; so that the same data
can be accessed several different times, within the timing requirements.

>My only requirement is to work with a "dial tone" choice system in
>order to cross
>a level based menu, structured like a tree data structure.
>I don't need to use voice I need only to make a menu and track the
>choices.

"voice" bandwidth is the only way to communicate to/from an end-user
via the public switched telephone network. You 'play' recorded audio
tracks that describe the menu choices. You 'listen' for the audio
tones that are the "touch tone" (DTMF) by which the user makes the
menu selection. Even though the user is not 'speaking' to the
computer system, the 'voice' channel is still required, to pass the
touch-tone 'commands', and the 'voice responses'.

>Are the two solutions proposed still the best
>approach?
>

You have a requirement for a certain level of capacity.

There are, essentially, _only_ two basic ways to get that level of capacity.

1) a single very large system -- what is called a 'monolithic' solution.
2) multiple small systems used 'in parallel'. this is commonly referred
to as the 'divide and conquer' approach.


(Note that in the above, there is _nothing_ being said about the nature of
the problem. This is a fundamental concept, applicable to any kind of
design engineering.)

For 'sophisticated' design situations, one may employ a mix of those
approaches. Example: doing database queries -- one may have a 'monolithic'
back end system that is the actual database and processing engine, and a
large number of 'paralleled' front-end units that do actual user interaction,
query formatting, input validation, etc, and then hand off the 'optimized'
already-validated request to the back-end, and, upon receipt of the response
from that back-end, do all the 'housekeeping' for displaying the information
to the use in a 'pretty' manner.

Which approach is better -- in terms of performance, and or cost -- for which
part(s) of the problem is extremely dependent on the _precise_ nature of the
problem that one is designing a solution for. And on the exact "mission
requirements" of the project. Things that do not "seem" like they would make
a difference can, in fact, turn out to be _critical_ issues.
.

Relevant Pages

  • Re: CFFA for IIc and IIc+?
    ... RAMWorks interface, without any impact on slot addresses at all. ... At this point I am guessing that the earlier memory interfaces for the //c were based on that RAMWorks style interface? ... Apple never built a RAMWorks-style memory card. ... widely available expansion AUX memory design for the //e. ...
    (comp.sys.apple2)
  • Re: Big-Endian vs. Little-Endian
    ... I once designed a machine with a 1 bit memory ... interface. ... However the basic design was very usable for some instruments, ...
    (comp.arch.embedded)
  • Re: Question to Interfaces/Objectcatalogue
    ... > members. ... The Classes implements the interface and offers only a Member ... I am sure I don't understand exactly why you are getting "memory problems", ... the original design is architecturally flawed from the ...
    (microsoft.public.vb.com)
  • Re: Chucks plan
    ... from having an automated memory bus, rather than the software driven bus? ... design was different, had to be designed separately, had ... This required predicting which memory chips will be most ... done with a Forth core and software this way. ...
    (comp.lang.forth)
  • Re: large binary immediately SEGVs
    ... said even running ldd on the load module caused ldd ... insisted in reducing any problem to a 4 assembler-level instruction ... memory, the text to be printed was clearly "Ready: ... Now you do not just walk into a design review and throw different ...
    (comp.os.linux.misc)
Loading