1 / 15

Effects of Clock Resolution on the Scheduling of Interactive and Soft Real-Time Processes

Effects of Clock Resolution on the Scheduling of Interactive and Soft Real-Time Processes. Yoav Etsion, Dan Tsafrir, Dror G. Feitelson School of Computer Science and Engineering The Hebrew University, 91904 Jerusalem, Israel. Key Ideas.

kunkel
Download Presentation

Effects of Clock Resolution on the Scheduling of Interactive and Soft Real-Time Processes

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. Effects of Clock Resolution on the Scheduling of Interactive and Soft Real-Time Processes Yoav Etsion, Dan Tsafrir, Dror G. Feitelson School of Computer Science and EngineeringThe Hebrew University, 91904 Jerusalem, Israel

  2. Key Ideas • The system clock has not increased at the same rate as the hardware clock • Scheduling algorithms are negatively impacted by this fact • Many applications could benefit from a faster system clock • A faster system clock could support soft real-time applications on a commodity OS • Increasing the system clock speed does not incur unreasonable overhead

  3. How did we get here? • The system clock has remained stable for almost 20 years • 1976 computer 3MHz CPU 60Hz Clock • 1 System tick per 50,000 instructions • 2003 computer 3GHz CPU 100Hz Clock • 1 System tick per 30,000,000 instructions

  4. Problems with direct scaling • Overhead: it takes around 400 clock cycles to process an interrupt • At the same approximate ratio, this would be an overhead of approximately 400 /50000, or only 0.8% • However, resulting caching degradation could raise this significantly

  5. Slow clock problems • Xine • Systems with clock speed of 100Hz cannot display 60 frames per second • Scheduling example • Accounting background for scheduling counts incorrectly with a slow clock

  6. Xine

  7. Priority Scheduling • Each process has a priority • Higher priority processes interrupt lower priority processes • Priority decreases while running • “Running” only checked on system ticks

  8. Scheduling Billing • Priority does not decrease correctly with inaccurate billing

  9. Increase proposal • What is the solution? • Increase the system clock speed • Examine 1000Hz - 20,000Hz

  10. Experiment Methodology • Computers used range fromPentium-90 (MHz) to P4 2.4GHz • Klogger was used to record context switches, priorities, forks, execs, etc • Applications include: Emacs, X server, Xine, Quake 3, custom CPU bound processes

  11. Overhead • Overhead cost is manageable

  12. Latency • Latency can be reduced from up to 420 ms to under 1 ms with 20,000Hz

  13. Review • System clock frequency is outdated • Increase would benefit applications and repair scheduler issues • Overhead for 1,000Hz or 10,000Hz not prohibitive • Soft Real-time support possible – latency under 1ms

  14. Analysis • Proposed as easy solution: “turn of a knob,” yet it involves modifying kernel code… probably not an end user thing • Could have spent some time explaining possible negative impacts (not overhead) of this increase, or justifying the fact that there are none. • Most overhead came from TLB and cache degradation. Could this be improved to compensate?

  15. Questions and Discussion

More Related