1 / 31

Predictable Scheduling for a Soft Modem

Predictable Scheduling for a Soft Modem. Michael B. Jones – Microsoft Research Stefan Saroiu – University of Washington. Consumer Real-Time. General-purpose Operating Systems, such as Windows 2000: maximize aggregate throughput approximate fair sharing of the resources

denis
Download Presentation

Predictable Scheduling for a Soft Modem

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Predictable Scheduling for a Soft Modem Michael B. Jones – Microsoft Research Stefan Saroiu – University of Washington

  2. Consumer Real-Time • General-purpose Operating Systems,such as Windows 2000: • maximize aggregate throughput • approximate fair sharing of the resources • Increasing use of time-dependent tasks • signal processing, audio, video • Need support for: • predictable scheduling for independently developed applications • low latency responses • explicit resource allocation mechanisms

  3. Why Study Soft Modems ? • Signal Processing done on host CPU: • requires predictable scheduling • requires low latency responses • While coexisting with other system activities • Soft Modem is a background real-time task • Successful in home computer market: • low cost • easy to update – software upgrade

  4. Methodology • Instrumented Windows 2000 performance kernel: • logs predefined and custom events • writes them to a memory buffer • dumps buffers to disk at end of trace • Driver Software: • no source for signal processing code • Measurement Environment: • all experiments run with normal-priority spinning competitor thread • System: • Windows 2000 Professional – Build 2195 • Pentium II 450 MHz (uniprocessor) • 384 MB ECC SDRAM - 100 MB allocated to logging

  5. Vendor Driver – Signal Processing in Interrupt (INT) • Operation of the modem: 1. DMA transfers between A/D and D/A and physical memory 2. when enough data samples, the modem raises an interrupt 3. inside ISR, process incoming data and provide outgoing samples, before buffers exhausted • Uses input and output data buffers holding 512 16-bit samples (1024 bytes/buffer)

  6. Three Additional Versions • DPC Version (DPC) • The ISR queues a DPC • DPC performs signal processing • Thread Version (THR) • The ISR queues a DPC that signals a thread via a semaphore • Thread performs signal processing • Experimented with several different priorities • Rialto/NT Version (RES) • Same as THR, but thread scheduled using Rialto/NT real-time periodic CPU Reservation

  7. Interrupt Rate 3 different phases, interrupts very regular Fall within PC 99 recommended interrupt rates of 3-16ms

  8. Elapsed Times in ISR (INT) 1.8 ms with repeatable worst case of 3.3 ms PC 99 recommends maximum time during which a driver-based modem disables interrupts should not exceed 0.1 ms

  9. CPU Utilization 14.7% sustained load on 450MHz Pentium II

  10. Elapsed Times in ISR (DPC) ISR times now small, typically < 6µs

  11. Elapsed Times in Queued DPC But now long DPC times: 1.8ms avg, 3.3 max (same as elapsed times in ISR for INT) PC 99 recommends that the total execution time required for all queued DPCs should not exceed 0.5 ms

  12. Samples Pending to be Processed(INT & THR 24) Small relative to 512 sample buffer size

  13. Samples Pending to be Processed (THR 8) Unsurprisingly, contention kills modem

  14. Latency Results • Set the multimedia timers to fire once every millisecond • Register a routine to be called every millisecond • Routine does very little work • stores cycle counter value and sleeps again • Histograms show differences between recorded times and ideal times

  15. Coexisting Thread Latencies (Control Case - No Modem) Maximum 1978µs between wakeups

  16. Coexisting Thread Latencies (INT) Maximum 5313µs between wakeups

  17. Coexisting Thread Latencies (DPC) Maximum 4396µs between wakeups

  18. Coexisting Thread Latencies (THR 24) Maximum 2239µs between wakeups

  19. What Have We Learned So Far ? • Signal processing in the context of the interrupt handler is: • unnecessary • detrimental to the latencies and predictability of coexisting activities • Vendor choice understandable: • for any priority there is a potentially unbounded delay between the interrupt and the thread running • In practice: • delays are reasonable [Intel OSDI ’99] • using interrupts extreme priority inflation

  20. Two Possible Solutions • Rate Monotonic Analysis – determine the “right” priority assignments among all threads - two problems: • assumes cooperative priority assignment among all threads - unrealistic • working priority assignment dependent upon timing requirements of all threads • changes in application mix may require changes in priority assignment • Use a time-based real-time scheduler • such as Rialto/NT

  21. Rialto/NT Abstractions • Two real-time software abstractions: • CPU Reservations – ongoing reservation for X time units out of every Y units for a thread • Time Constraints – one-shot time reservation for certain amount of work between start time and deadline • The Soft Modem work only uses CPU Reservations

  22. Rialto/NT Implementation • Rialto/NT developed on top of Windows 2000 scheduler • Limitations: • CPU Reservations must be integer multiples of milliseconds • Frequency of reservations must be power-of-two multiple of 1ms

  23. Samples Pending to be Processed (RES 2ms/8ms – 25%) Fits well within 512-sample buffer size

  24. Coexisting Thread Latencies (RES 2ms/8ms – 25%) Maximum 1971µs between wakeups

  25. File Transfer Times Results for 10 copies of 200,000 bytes each For 1/8, 2/15, 3/17, 4/17, 7/20 no test passed

  26. Modem Reservation Ranges Sensitivity to both percentage and gaps If period < 12.5ms, must get 14.7% to work If period > 12.5ms, (period – amount) >= 12.5ms must also hold

  27. Conclusions • Signal Processing in interrupt context is: • Unnecessary • Detrimental to the predictability and latencies of the coexisting activities • The DPC version has similar problems • Threads help alleviate these problems • Modem runs well with real-time priorities and non-real-time competition • However modem threads may interfere with other threads • Real-time scheduler allows • Control over modem’s degree of interference with other time-sensitive activities • Performance isolation for threads using reservations

  28. Industry Perspective • Vendor DID build their own THR version • Worked fine during normal load • However, modem was starved when • copying data between two IDE devices • using USB scanner (Intel 440BX chipset) that turned off interrupts for 30-50 ms • Therefore they shipped the INT version • Vendor willing to be ‘good citizen’ • if ensured that others would be as well • Systematic latency timing verification of components can enforce good-citizen behavior

  29. Soft DSL is Coming • More demanding than soft modems • 4ms processing period • G.lite • 1.531Mbps downstream and 512Kbps upstream • ~ 25% of a 600 MHz Pentium III • Full rate DSL • 3.062Mbps downstream and 512Kbps upstream • Nearly 50% of a 600 MHz Pentium III • Soft Bluetooth period 312.5µs

  30. Further Research Possibilities • Soft DSL studies • Multiple soft devices within the same machine • Similar studies on multiprocessors

  31. For More Information • See the authors • Mike Jones • mbj@microsoft.com • http://research.microsoft.com/~mbj/ • Stefan Saroiu • tzoompy@cs.washington.edu • http://www.cs.washington.edu/homes/tzoompy/ • Microsoft Research Tech Report • MSR-TR-2000-88 • See related papers at Mike’s website

More Related