While working on my presentation for BriForum on Perceived Performance, I was reminded of another performance related white paper that I wrote seven years ago titled It's Time to Change the Timers, which was about the need to change the basic system clock interrupt provided by the Hardware Abstraction Layer (or HAL) that sets timer granularity in the OS. With Microsoft working on Windows 8, maybe it is finally time to look again at this issue. During those seven years, the examples I gave have only been amplified by even faster technology, both in processors and peripherals, and the simplification of the windows HAL to assume multiple processors. Our systems could perform better.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
The crux of the issue
At the heart of the Windows Operating System is the windows timer. My first PC, a Compaq clone called Deskpro, used a 55ms timer back in the good old DOS days. I think it was around 1984 and yeah, it booted off of floppy drives. The CPU ran at 4mhz (7mhz if you pushed the "turbo" button). In the 1990s, Microsoft introduced Windows NT. I ran it on single CPU machines with a 333mhz processor. The basic clock provided 10ms granularity. If you put it on a dual processor machine, this jumped to 15ms. Microsoft used two different HAL packages, one for single processor and another for multi-processor. The clock is dictated by that HAL.
The timer plays several important roles in the system. An obvious one is that if some software wants to sleep for a period of time, then wake up, it sets a timer to do this. The system timer dictates the granularity, and importantly the minimum wait period. So if the software wants to wait 3ms, it is going to wait for the full timer length. This timer also affects things like thread scheduling, the effective quantum time (how long a thread can chew up a processor before being thrown out), and even how often certain other kernel activities can happen.
What's in your PC?
Chances are you are reading this using a computer with multiple processors (in this audience I'd guess 4 logical processors present), probably running in the ballpark of 3Ghz. The clock you get is set to 15ms (rather than 10ms) because Microsoft got rid of the two HAL images and always use the multi-processor one, even if you had only a single processor.
In one time interval my Compaq Deskpro with the turbo on could execute potentially 440 thousand instructions (Note: the reality is that instructions take more than one machine cycle but let's just ignore that complication in the math - it washes out). Using that math, the NT system could execute 3.3 million instructions in its timer interval. On the system I'm guessing you are using, it would be over 80 million instructions executed before the timer expires. That is a heck of a lot of instructions.
Why should you care?
Modern software design practices tend to avoid setting short term timers because, in part, the granularity of clock is not small enough for todays systems. Instead, they use asynchronous calls which instead puts the burden on the kernel of the OS. But there is still a lot of software out there depending on the timer that would work better if Microsoft made the timer shorter. Rogue processes would be better controlled, and VM clock slew might just be lowered. Ultimately, I believe users will receive better "perceived performance".
Sometimes timers need to be appropriate for off CPU activities. But even many of these activities have significantly sped up since I wrote the original paper in 2004. Our networks are faster (although there is no solution to the speed of light latency over long distance) and our peripherals run at faster interfaces as well. Speeding up the timer would allow some applications to perform better with todays hardware.
The downside is what would break. But Microsoft has some smart people and I'm betting they can work out a way. Even if it is to implement a faster clock, say 1ms granularity, for the kernel itself and for applications that specifically request the more granular clock.
And it might be too late for Windows 8 (or whatever it gets called when it is released), since Microsoft is well into the design. But I assume there will be a 9. Eventually this needs to change.
Author: Tim Mangan is a Microsoft MVP for App-V, a Citrix CTP (I know, redundancy) and holds the position of Kahuna at TMurgent Technologies. He has spoken at every BriForum and at many other venues. Read more at his home blog or website.