# Worst-case resource management calculation

One way to find out if the available board resources can support all the processes is to calculate the resources required by the application in its most demanding scenario. This is called a worst-case scenario calculation.

When pool sizes are specified in the board keyword file, the CG boards calculate the requested resources at boot time and determine if the requested DSP resources are available.

This topic describes a worst-case resource usage example (a telephony application using an on-board CAS or ISDN protocol) to illustrate the methods used to calculate resources under particular conditions.

## Example

For calls in the connected state (also called the conversation state), media processing functions (that is, vocoders or fax functions) consume the greatest amount of DSP processing power. TCPs used during the call also require DSP resources, but they use the greatest amount of resources during the set up phase of the call. In general, the resources required during call setup are less than the resources required in the connected state. For this reason, the examples that follow calculate resources used during calls in the connected state.

The following example shows resource requirements for a call that uses the following functions in the connected state:

- Software echo cancellation (echo.ln20_apt100 DPF)

- DTMF detection with energy detector and two tone detectors (dtmf.det_all DPF)

- Precise tone detection (ptf.det_2f DPF)

- NMS ADPCM record vocoder (voice.rec_32 DPF)

This example assumes that the worst-case usage (that is, the point where DSP resources experience their highest MIPS usage in every category) occurs during the connected state of the call.

ISDN signaling and out-of-band signaling for CAS use signaling resources executing on the control processor. The DSP resource manager does not manage these resources.

The following table shows approximate resources consumed by the DSP functions in this scenario:

DPF | MIPS | Input slots | Output slots | Data memory | Input Pkt queue | Output Pkt queue | DSP-to-coprocessor buffer size | Comments
--- | --- | --- | --- | --- | --- | --- | --- | ---
echo | 4.0 | 2 | 1 | 800 | 0 | 0 | - | 20 ms length, 100% adapt rate
dtmf | 2.5 | 1 | 0 | 200 | 0 | 0 | - |
ptf | 1.3 | 1 | 0 | 100 | 0 | 0 | - |
voice | 3.3 | 1 | 0 | 300 | 0 | 1 | 40 | NMS Record 32 kbit/s
Port resource consumption | 11.1 | 5 | 1 | 1400 | 0 | 1 | 42 |

To find the most up-to-date resource requirements for specific DPFs, run f41info as described in f41info - Displaying DPF file resource usage.

## Resource calculations

Based on the previous example, you can calculate the following resource limitations for the sample application:

Resource category | Worst case usage
--- | ---
MIPS | MIPS used by this worst case example are the sum of the MIPS requirements for all of the functions, or 11.1 MIPS. Divide the 128 MIPS (approximately) available per DSP core by the sum, and truncate the result (128 / 11). This example yields 11 ports of conversation state per DSP core.
Memory | Each DSP core has 64 K of data memory that is used for both data and context. This example assumes 20 K words of data/context memory. As a result, the limiting factor for memory is the amount of context memory needed per port. In this example, the number of ports that can be allocated from memory are (44 x 1024) / 1400 = 32.
Timeslots (input and output) | Each connected port consumes one full duplex timeslot because input slots are shared. Furthermore, two of the echo canceler slots, one input slot and one output slot, are internal. The port limit per DSP core due to timeslots is 32 ports for both external and internal slots. If the total input or output timeslots calculation is greater than 1, the resource manager sets it to 1.
Packet queues | The number of packet queues required in the example is 1. The packet queue limit is therefore 64 (64 / 1).
Buffer size | The coprocessor packet size limit is applicable only for DSP functions sending or receiving data from the coprocessor. Typically, this limit is imposed by a vocoder in the conversation/connected state. Since this example uses a voice recording DPF, the packets take up resources in the DSP-to-coprocessor buffer. An NMS 32 kbit/s vocoder uses 42 words (40 words of data, 2 header words) per coprocessor packet, resulting in an 18 port per DSP core limit (obtained by dividing DSP-to-coprocessor buffer size by packet size or 768 / 42). An NMS 64 K vocoder uses 82 word buffers in a connected state, and therefore limits each DSP core to nine ports. In the case of play functions, the packets consume resources in the coprocessor-to-DSP buffer plus an additional four words in the DSP-to-coprocessor buffer. This is because the DSP operating system sends data acknowledgment events through DSP-to-coprocessor buffers.

### Overall resource requirements

In this example, the number of ports per DSP core is limited to a total of 11 by the MIPS requirements.