Thread: Time

Originally Posted by matsp

Because it sits on a PCI device (southbridge), it takes quite a few cycles to "get there", so it's not a good idea to read it frequently, thus the OS won't do that.

Are you shure Mats? The Linux kernel has HPET_TIMER for ... over a year? ... now. And it's explained with:

This enables the use of the HPET for the kernel's internal timer. [...]

Also I think wrapping is not a problem. HPET can be used as callback timer, so it calls functions (also userspace ones) at defined intervals

Originally Posted by pheres

Are you shure Mats? The Linux kernel has HPET_TIMER for ... over a year? ... now. And it's explained with:



Also I think wrapping is not a problem. HPET can be used as callback timer, so it calls functions (also userspace ones) at defined intervals

Yes, that's EXACTLY what it is for - to get code in the user-mode application to run in a timely manner, and as long as you don't expect it to be VERY precise[1], it will work just fine.

My point was about using the HPET for precise timing excercises, such as measuring the time of a function, which is what the original post asked for. Reading a HPET timer from a PCI bus is not something you want to do several times in a microsecond - each access will take several PCI cycles, which are 30ns each - perhaps as much as 200 ns - we are now talking 20% of a microsecond.


[1] Linux is not a RTOS, so interrupt latency and kernel to user-mode latency is not in the "single digit or fractions of microseconds region", which a dedicated RTOS on a 100MHz processor should be quite capable of as a worst case, and better on average numbers.

--
Mats