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 Engineering The Hebrew University, 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 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

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

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