X hits on this document





4 / 5

the latencies that are achievable on an idle system.

The damage the soft modem’s long-running ISR or queued DPC causes to the coexisting callback routine is evident. Notice, in particular, that the tails of the distributions increase from 2ms to over 5ms.

Figure 7 illustrates the callback latencies for the THR driver version. As before, the THR uses a priority 24 real-time thread.

3.6 Reflections Upon the Vendor Choice

Figure 7 – Latency histogram for a 1ms callback routine – THR version (THR 24)

Given that thread-based signal processing works well and causes less disruption of coexisting system activities, why then might a vendor still chose to perform signal processing in DPCs or in interrupt handlers? Vendors face a problem common to all priority-based open systems (ones in which independently authored applications and/or drivers may be executed): for any chosen priority, there is a potentially unbounded delay until a thread is scheduled to run. These delays can be caused by other applications running for arbitrary periods of time at the chosen or higher priority. Thus, no timing guarantees can be made.

For systems with a fixed priority preemptive scheduler, like Windows NT, it is possible to use Rate Monotonic Analysis (RMA) to determine when each of the system threads should be scheduled to run according to their deadlines. Unfortunately, RMA cannot be employed due to the following reasons:

RMA assumes cooperation between the threads, which is unrealistic given the existence of different drivers written by different vendors

RMA assumes constant timing requirements for all the coexisting threads. More precisely, whenever a thread changes its CPU requirements, it potentially affects all the other coexisting threads.

We believe that a better alternative to RMA would be a real-time scheduler, such as Rialto/NT. The coexisting threads could then reserve ongoing portions of the CPU, using the CPU Reservation abstraction.

3.7 Coexistent Thread Latencies in RES Version

After trying different values for the CPU Reservation and due to the coarse-grained accuracy of the Rialto/NT prototype, we decided to use a 2ms/8ms reservation for the soft modem. Figure 8 shows the callback latencies for the RES version with a 2ms/8ms CPU Reservation. The

predictability of the callback routine improves substantially over the INT and DPC versions. Compared to the THR version shown in Figure 7, there are two times more callbacks occurring within 50μs from 1ms.

3.8 Elapsed Times per Wakeup in RES Version

Figure 8 – Latency histogram for a 1ms callback routine – RES version (RES 2ms/8ms)

Figure 9 presents the work done by the signal processing thread when scheduled with a 2ms/8ms (25%) CPU Reservation.

Figure 9 – Elapsed times in thread run RES 2ms/8ms– 25%

While larger as a percentage than the actual modem requirements, a 2ms/8ms reservation is not an ideal match for the soft modem processing routines. The period of 8ms causes the signal processing thread to be scheduled to execute at different times than the occurrences of the interrupt. Whenever scheduled, the thread will cede its reservation to the normal spinning competitor if it is not in a ready state. This explains the long processing times of single thread runs, since they also incorporate the times spent in contexts that preempted the measured thread. However, despite the period mismatch, this reservation does allow the modem to operate perfectly, as the results in the next section show.

3.9 End-to-End Modem Download Throughput

We also measured the time required to transfer a file of 200,000 bytes. For each version of the driver, 10 copies of

Document info
Document views20
Page views20
Page last viewedMon Jan 23 19:27:55 UTC 2017