Re: High-precision timers - independent of HZ right?

4805455@xxxxxxxxx wrote:
On Jan 30, 12:57 pm, nob...@xxxxxxx (Kevin the Drummer) wrote:
4805...@xxxxxxxxx <4805...@xxxxxxxxx> wrote:
Hello. I have compiled the 2.6.19 kernel with Ingo Molnar et al's
2.6.19-rt15 patch. I also enabled the high-precision timers in the
config before building the kernel. I boot this kernel and I have a
program that asks for a timer tick at various rates.
Despite the high-resolution timer, I cannot get a 1 millisecond timer
with any accuracy. This may be scheduling latency, but I have the rt
patch installed. I am running an unloaded 1.4 MHz pentium M and
CONFIG_HZ is 250 (which should be irrelevnat right?). Has
anyone gone through all this yet? There doesn't seem to be a lot of
documentation on it, just the patches.
I can't tell what's independent and what's dependent. Try changing
CONFIG_HZ to 1000 and see if it makes a difference. Please do let us
know what you find.

Thanks!

--
PLEASE post a SUMMARY of the answer(s) to your question(s)!
Show Windows & Gates to the exit door.
Unless otherwise noted, the statements herein reflect my personal
opinions and not those of any organization with which I may be affiliated.


Well, if I make CONFIG_HZ be 1000 then I definitely get 1 millisecond timers, but what if I want even smaller? I thought the high-
resolution timer patch was tog et around CONFIG_HZ.

Anyway...I'm considering buying from a vendor like BlueCat to have them solve all this.


Dunno if it helps, but years ago I did something like this on a 386...reprogrammed the timers to run much faster, and then wrote a patch ISR that chained into the standard ISR..and only passed control to it every few timer pulses..that gave me a fast and precise way to stick a signal into something low level I was working on.

A separate board with a timer may be another way..but experience suggest you may have to hack interrupts and the main kernel timer routines.

I am not sure what you are trying to do, but fast accurate real time stuff is generally better handled by a separate board with its own processor. Linux and most multi tasking multusuer OS'es have sch variable latency is not wise to rely on them in time critical stuff..which is why just about every IO channel has some sort of buffered processor in it.




Jim

.

Relevant Pages

  • Re: [PATCH 1/2] Dynamic Tick: Prevent clocksource wrapping during idle
    ... The dynamic tick allows the kernel to sleep for periods longer ... This patch prevents that the kernel from ... kernel can sleep for a given clocksource and function called ... there is no timer pending or at least extremly far ...
    (Linux-Kernel)
  • Re: select & gettimeofday
    ... > timer, and since you would usaully use it to poll some fds, it will ... > break either before the timeout value (due to a descriptor becoming ... The kernel on the 2.6.1 machine is SMP, ... But I don't know if the patch has made it into 2.6 (I think ...
    (comp.os.linux.development.system)
  • Re: gettimeofday nanoseconds patch (makes it possible for the posix-timer functions to return higher
    ... >>I am working on some timer issues for the IA64 in order to make the timers ... >>resulting usecs are multiplied by 1000 to obtain nanoseconds. ... I'm not a fan of the patch. ... It realistically only helps ia64 ...
    (Linux-Kernel)
  • Re: [BUG] IO-APIC + timer doesnt work!
    ... Could you try if writing 'delta' a second time makes any difference on ... But then you read on about changing the period of a running timer: ... I've provided a patch to partially ... write 'delta' a second time. ...
    (Linux-Kernel)
  • Re: [RFT 2/4] Add mod_timer_noact
    ... It does not mention the overhead to the regular timer interfaces ... Not a good sign if you are trying to get a patch ... all i'm doing here is reviewing patches of subsystems ... Linux and post core kernel patches to lkml, ...
    (Linux-Kernel)