System Performance: It's (still) time to change the timers!

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

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.

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

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.


Tim Mangan  

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.

Join the conversation


Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

Hi Tim,

Interesting observation, but I assume we can be sure that if increasing the granularity of the timer can improve the (perceived) performance, that Microsoft would definitely be looking at it. What I am missing a bit in your article is the reason why this is capped to 15 milliseconds for multicore HAL's -- I am pretty sure there is a good reason (unbeknown to me) why we are not all having high resolution timers (HRT) in our desktops...




On multiprocessor systems that are not fully loaded with thread execution, doesn't intelligent tick timer distribution (2008 R2 / Win7 only) minimize the amount of wasted CPU cycles?  I mean you're still going to hit the default 15ms cycles on the loaded processor, but theoretically the other CPUs on the system could avoid timer interrupt if there was no work to be done.


Also can't applications be coded to use user mode scheduling as a way to improve perceived performance / reduce context switching without having to resort to wasted cycles through kernel scheduling / timer interrupt?  It seems that would be a more effective way to address the problem than to later the timer interval.  Even though it does mean recoding.


This burden has been shifted to the kernel, its a no n issue IMHO, and the reason they havent messed with it is because the downsides are great and benefits nill.