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 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

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

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

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

Xine

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

Scheduling Billing Priority does not decrease correctly with inaccurate billing

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

Experiment Methodology Computers used range from Pentium-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

Overhead Overhead cost is manageable

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

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

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?

Questions and Discussion