X hits on this document





1 / 5

Predictable Scheduling for a Soft Modem

Stefan Saroiu

Department of Computer Science & Engineering

University of Washington

Seattle, WA 98195-2350, USA



Michael B. Jones

Microsoft Research, Microsoft Corporation

One Microsoft Way, Building 112/2156

Redmond, WA  98052, USA




Soft Modems use the main processor to execute modem functions traditionally performed by hardware on the modem card. To function correctly, soft modems require that ongoing signal processing computations be performed on the host CPU in a timely manner. Thus, signal processing is a commonly occurring background real-time application—one running on systems that were not designed to support predictable real-time execution. This paper presents a detailed study of the performance characteristics and resource requirements of a popular soft modem. Understanding these requirements should inform the efforts of those designing and building operating systems needing to support soft modems. Furthermore, we believe that the conclusions of this study also apply to other existing and upcoming soft devices, such as soft Digital Subscriber Line (DSL) cards. We conclude that (1) signal processing in an interrupt handler is not only unnecessary but also detrimental to the predictability of other computations in the system and (2) a real-time scheduler can provide predictability for the soft modem while minimizing its impact on other computations in the system.

1. Introduction

Soft Modems use the main processor to execute modem functions traditionally performed by the digital signal processor (DSP) on the modem card. While soft modem hardware retains A/D and D/A functions, CPU-intensive computations, such as signal processing, are performed on the host CPU. We measured a 14.7% sustained CPU load on a Pentium II 450 MHz machine. Because soft modems do periodic real-time computations on the host CPU in order to maintain line connection and transmit data, a mechanism ensuring periodic computations is essential.

We analyzed the driver of a popular soft modem1 in order to better understand its real-time characteristics. Currently, the vendor version performs its digital signal processing work in interrupt context. We modified this driver to produce three additional versions by executing the signal processing code in the context of a Deferred Procedure Call (DPC), a thread scheduled by the Windows NT scheduler and, finally, a thread scheduled using the CPU Reservation abstraction of the real-time Rialto/NT scheduler [Jones & Regehr 99], respectively.

1 Our agreement with the manufacturer prevents us from identifying this soft modem.

We conclude that signal processing in interrupt context is not only unnecessary but also detrimental to the predictability of other computations in the system. While DPCs and time-based scheduling have milder side effects upon the rest of the system, nevertheless, they suffer from some of the same drawbacks as the original version. Real-time scheduling for commodity systems provides a good answer to the observed predictability problems.

Finally, we believe many of the lessons learned from studying soft modems are applicable to a wider class of problems. Other soft devices are already in use, with more coming soon. For instance, software-based Digital Subscriber Line (Soft DSL) [Tramontano 00] devices have been announced.

2. Soft Modem Driver Versions

The soft modem uses Direct Memory Access (DMA) to transfer the data between the A/D and D/A, and the physical memory. There are four different buffers—two output buffers (one for data and one for voice samples) and two input buffers. Each buffer has a size of 512 16-bit samples, for a total of 1024 bytes. Our experiments traced the data buffers only.

We compared and contrasted four versions of the soft modem driver:

Vendor version (INT) in this initial version of the driver, when the card interrupts the CPU, the driver software performs the signal processing inside the interrupt handler (a.k.a. Interrupt Service Routine or ISR). Both outgoing and incoming samples are processed.

DPC version (DPC) – this version executes the signal processing code in the context of a DPC. When the modem card raises an interrupt, the ISR queues a DPC.

Thread version (THR) – in this version, the signal processing routines are executed in the context of a regular thread with a given priority and scheduled by the Windows NT scheduler.

Rialto/NT version (RES) - in the final version of the driver, the signal processing thread is scheduled using the Rialto/NT scheduler using a CPU Reservation.

Threads make CPU Reservations to ensure a minimum guaranteed execution rate and granularity. CPU Reservation requests are of the form reserve X units of time out of every Y units for thread A. The current implementation of Rialto/NT has two restrictions: (1) CPU reservations must have values that are integer multiples of milliseconds since they are driven off the periodic Windows NT clock and (2) the period of a reservation must

Document info
Document views8
Page views8
Page last viewedMon Oct 24 04:26:41 UTC 2016