OSDev.org

you thought your latest readings about ACPI taught you whatever you wanted to know about modern interrupt management ? wrong. they managed to get yet something else: High-Precision Events Timers.

Since we were kindly asked to give notes about it on [email protected], i'm posting what i've found so far ...

The specifications (free for download)
http://www.intel.com/hardwaredesign/hpetspec.htm

The ICH6 (intel chipset) seems to support HPET
http://www.intel.com/design/chipsets/da ... 147302.pdf

And microsoft seems to have a nice word to say about it and why it's so great and why we should all upgrade to systems having it supported, etc

http://www.microsoft.com/whdc/system/CE ... =true#img1

Oh, praise ole santa for this nice piece of news, ye olden bucks!

Ah, St. Gnucius will turn green and envy will devour him.

[hilarious mode off /]

Maybe if one can afford a new board that fast, it *might* find an implementation, else *shrugs*. No Hardware to test - no implementing.

Hi,

From Microsoft's article:

"Current timers theoretically have a maximum resolution of 1 millisecond and an achievable resolution of 2 milliseconds because of performance concerns."

Are these morons serious?? The PIT has a resolution of roughly 838 nS - over one thousand times more precise than the 1 mS resolution they are complaining about.

"In the previous example, the clock interrupt period was lowered to 1 millisecond to play a sound at a precise time. This resulted in 10 interrupts being generated between the times 230 milliseconds and 240 milliseconds while only one interrupt was actually needed. A better approach to this problem is to only schedule an aperiodic timer interrupt when there is work to be done."

OK - so I can assume Microsoft haven't figure out how to use the PIT in "one-shot" mode then. Perhaps they should read some technical material before designing the OS? Even the RTC's periodic interrupt can handle the example they present without problems.

"Although the current timers are still in use and still function properly, they do not meet the needs of time-sensitive applications and depend on legacy technologies such as the Industry Standard Architecture (ISA) bus. To migrate away from these legacy technologies, and to eliminate redundant hardware in the chipset, a new timer is needed that can replace the existing hardware."

ROTFL - reduce the legacy stuff! I find it much more likely that it'll just add more and won't reduce the legacy stuff at all. I can't think of any single case where new technology has ever removed legacy stuff in "PC compatible" computers - the best we could hope for is "legacy emulation only" (like USB keyboard & mouse emulating the PS/s devices through SMM - arguably more messy, not less).

I wonder what the real reason Microsoft wants HPET is....

Let me see. Getting rid of ISA? Not likely, it's been gone for ages (integrated into the LPC bridge in PCI chipsets a long time ago). Getting rid of the RTC? The RTC keeps time when power is off while the HPET won't, so that isn't possible.

Getting rid of the PIT? It would be highly unusual, but if Microsoft can convince hardware manufacturers to make computers without a PIT, then OSs like Windows 9X and WIndows XP won't run on the new hardware, so people will have no choice but to upgrade to Longhorn/Vista. Maybe this is the real reason - after all Win9x and WinXP will be Microsoft's largest marketting problem.


Cheers,

Brendan

This actually makes me ask a completely unrelated question: Do the Pentium Pro and up have precise interrupts anymore, or is that just a legacy feature?

And just why do we need a new damned timer to program? As shown b y the previous posts, we already have 2.

I suspect they are talking about a design limitation in MS Windows actually . They also say "achievable resolution of 2 ms because of performance issues". I guess that's due to a buch of code that seriously goes wrong at a higher frequency - but not the hardware's fault.



Well that's exactly what I planned to do in my implementation. Use the timer interrupt in one-shot mode for asynchronous events - I have not yet seen a problem with this.

Btw, I don't like the way they write these papers >:(. And that not only because they push shortcomings in software (read the above paragraphs) to hardware. Also some other, rather subtle things.

cheers Joe

I don't like in the FAT document how they say:



erm... no, the important thing would be for us to understand it.

Not really. You implement a FAT driver for compatibility with Microsoft operating systems, which the majority of PC users use, making it much easier to move data between your OS and Microsoft's. If Microsoft implemented their own filesystem technically wrong, you would too, since there's no point outside of compatibility for such a stinky filesystem. The FAT document is more about how to be compatible with Microsoft's implementation of the filesystem than why and all those fascinating design (or lack thereof) details.

As revealed in the next sentence:



In fact, they even go on to say:



Surprisingly simple and yet too complicated to explain? As far as I'm concerned, the document writer was just being lazy (as reinforced by other comments in the document).

I have to let them off due to the humour value of the writer using the document to rant about how annoying it is having to be backward compatible though.

Possibly. An algorithm can be easy to do, that doesn't mean that *why* it works is not complex.

Hi,



Hmmm - what are precise interrupts?



There's the local APIC too (3 timers!) which is much more precise as it uses a 64 bit counter and it's frequency is derived from the CPU's bus speed. Microsoft actually are correct in that power management can interfere with the accuracy of the local APIC timer, which (depending on what you use it for) may or may not be a good or bad thing. For e.g. using it to measure real time in any way is a bad idea, but using it to measure the amount of CPU time used is a good idea (IMHO it's great for schedulers, which isn't too surprising as that's what it was probably designed to be used for). They neglected to mention that hyper-threading can also make the local APIC timer a little tricky (might need some form of work-around, depending on what the local APIC timer is being used for).

As for Microsoft's article, it was probably written by the marketting department rather than anyone with any technical knowledge - an honest technical person would probably have had difficulty ("Our OS's timing is so bad we need new hardware" just doesn't sell too well ).

I guess one reason why they might want to shift the HPET is non-PC compatibile hardware - for example, a "media center" and/or a games machine using Intel compatible CPU/s and proprietory hardware, running a cut down version of Windows. This is probably the most likely reason I've thought of so far (i.e. use HPET as a way to reduce legacy hardware in proprietory devices rather than in 80x86 compatible computers)...


Cheers,

Brendan

I quote the four properties of precise interrupts, straight from textbook:


In the case of an x86, the PC would be the eip register. According to these properties, at least, it's easier to deal with precise interrupts for an operating system coder, and far harder for imprecise interrupts that don't give you a known state on interrupt.

Hi,



Ahh - OK. In this case, all 80x86 CPUs do or don't support precise interrupts, depending on how much execution state you expect to be saved. All 80x86 CPUs behave in a similar way.

For interrupts, the CPU always saves CS, EIP and EFLAGS, and may save SS, ESP (if the interrupted code wasn't running at CPL=0 and the interrupt handler isn't using a conforming code segment), and might also save DS, ES, FS, GS (if virtual 8086 was interrupted).

Of course this depends on the IDT descriptor too - for an interrupt task gate it does a full hardware task switch, where everything is saved (except the FPU/MMX/SSE/SSE2 state), but most people never use these for performance reasons.

Typically the general registers (except for the interrupt task gate option) are not saved or restored by the CPU - this must be done by the interrupt handler itself.


Cheers,

Brendan

It never makes sense for interrupts to be imprecise (except perhaps NMIs), but sometimes it makes sense for certain exceptions. The only kind of imprecise exceptions I've heard of in practice are FP exceptions on some RISC architectures, and aborts on x86 (usually there's an option to make FP exceptions precise at the cost of performance, but on x86 they're always precise AFAIK).

From the Holy Intel Manual --



The only aborts on x86 that I know of are double fault and machine-check exceptions.

Good, now I can give Tanenbaum a good smack for scaring me with that talk of later Pentiums (after Pentium Pro) being superscalars that merely emulated precise interrupts. I had begun to think that newer processors (such as the hyperthreading P4s) might have had the feature dropped from emulation, or that precise interrupts might have been dropped from Itanium or Opteron.

Well, they are superscalar. Any pipelined processor pretty much has to "emulate" precise interrupts by flushing the pipeline. It just gets trickier with out-of-order execution and longer FP pipelines, but that's a concern for the CPU designers fortunately.