http://meld.mvista.com/group_discussion.aspx?discussionid=e96493413c2a42bebdac60cfc5247840
|
Hello All,
>From my previous thread (Polling GPIO Pin status) I learned that to
achieve high timer precision I should use hrtimers (high-res timers).
Please correct me if any inputs I should consider before using it,
thanks.
I have mpc8313erdb eval board with Linux 2.6.20. I am using LTIB
tools framework to build kernel image. I checked in my kernel
configuration but I could not find CONFIG_HIGH_RES_TIMERS option
in Kconfig. That means I do not have hrtimer support in my kernel and I
should apply patch of it to the kernel. Right ? ? ?
Unfortunately I could not able to find hrtimers patch for kernel V
2.6.20, could anyone please send me the link from where I can download
it, thank you. Please send any more relative information regarding
using hrtimers.
Kindly please acknowledge ... thank you ...
Kind Regards,
Vijay Nikam
Posted 3/28/2009
8:50 AM |
|
|
hi vijai,
iirc the hrtimer API has been merged in 2.6.21. i found the
following patch from thomas gleixner (one of the hrtimer authors),
which seems to add hrtimer support to 2.6.20: http://www.kernel.org/pub/linux/kernel/people/tglx/hrtimers/2.6.20/patches-2.6.20-hrt-dynticks1.tar.bz2.
i don't know if it includes support for ppc, at a first glance i don't
see a specific patch for this architecture. another option is updating
to a more recent kernel, 2.6.20 is fairly outdated
best regards
Matthias Kaehlcke
Posted 3/28/2009
1:24 PM | 1
|
|
@ Matthias
thanks for the link.
Actually later I checked in the kernel source and found the files
for hrtimer ... hrtimer.h, hrtimer.c and hrtimers.txt are present also
the object file (hrtimer.o) is present. So I think I already have
hrtimers support in the kernel ? ? ? Please correct me if I am wrong.
I read the txt documentation; in testing and verification part they
said the following:
" We used the high-resolution clock subsystem ontop of hrtimers to
verify the hrtimer implementation details in praxis, and we also ran
the posix timer tests in order to ensure specification compliance. We
also ran tests on low-resolution clocks.
The hrtimer patch converts the following kernel functionality to use
hrtimers:
- nanosleep
- itimers
- posix-timers "
So now I would like to ask following questions:
1. How I can verify that posix-timers (timer_create and
timer_settime) are using high-resolution timers??? If I already have
hrtimers support in my kernel then why I am not getting precise timer
resolution ? ? ?
2. If it is present then how I can use the hrtimers functionality ?
? ? Also hrtimers changes the functionality of posix-timers, so does it
mean that I should use the same API (timer_create and timer_settime) or
hrtimers has different API that I should use ? ? ? Also one important
thing is I am using posix-timers in user space !!!
3. Also is there anyother way to verify hrtimers functionalityi is
enabled? ? ?
Kindly please acknowledge ... thank you ...
Kind Regards,
Vijay Nikam
Posted 3/30/2009
4:01 AM |
|
|
unfortunately
the presence of hrtimer.c, ... doesn't necessarily indicate that your
kernel supports hrtimers. the hrtimer patches merged in 2.6.16 provide
a basic framework for hrtimers which is used as base for the
re-implementation low-resolution timers. you can use the hrtimer API
but won't get more than jiffies resolution unless CONFIG_HIGH_RES_TIMERS
is enabled, which was merged in 2.6.21.
further your system needs a clocksource with high resolution and it
must be configured in the kernel, i don't know if this is the case for
your platform. have a look at http://ntnu.diva-portal.org/smash/get/diva2:124182/FULLTEXT01
(page 44-) for more information about hrtimer internals.
after having installed a kernel with CONFIG_HIGH_RES_TIMERS
enabled you can check the clock resolution of your clocks in
/proc/timer_list to see whether you really have high resolution
available or not
best regards
Matthias Kaehlcke
Posted 3/30/2009
6:57 AM |
|
|
@Matthias
thanks for the very useful document.
I think the kernel upgrade will be the better option. but before
doing that I will try to enable it my existing linux-2.6.20. for a try.
I will keep the above document as reference. Ofcourse the arch is
different but would like to give a try.
I would like to ask by any chance can I get the more details of the
implementation given in the above document ? ? ?
kindly please acknowledge ... thank you ...
Kind Regards,
Vijay Nikam
Posted 4/4/2009
7:51 AM |
|
|
for
more information about hrtimers i recommend you Wolgang Mauerers book
"Professional Linux Kernel Architecture" (ISBN: 978-0470343432).
Chapter 15 "Time Management" gives a detailed introduction to linux
timers and hrtimers
Posted 4/4/2009
8:51 AM |
|
|
I have a different
question, on what seems to be obvious to absolutely everybody except
for me:
What are the practical use cases for HRtimers? I.e. what type of
applications use this API?
I haven't seen that discussed anywhere, everybody seems to discuss
*how* to achieve nanosecond precision, not *why*.
Any informed knowledge here?
Posted 4/22/2009
3:19 AM |
|
|
Hi Linus,
The typical Linux timers are limited by the resolution of the
system HZ rating. So, if the HZ is set to 100, the best resolution you
can get is 10 ms. Now, if you need a higher resolution, you could set
the HZ value to as high as 1000. But, changing the HZ effects a lot of
different subsystems in the kernel. So, ideally, you should be able to
use an alternate timer approach wherein you set the time you want it to
go off and an interrupt occurs once rather than setting up a periodic
interrupt. This is basically what the HRtimers do.
However, the HRtimers implementation is typically tied to the
process clock ala the TSC or a high-res PIT or the like. This also has
the effect of being able to deliver a timer resolution that is in line
with the CPU clock frequency -- but still not via a periodic interrupt.
This implies a much lower level of effort on the part of the system as
a whole, because the CPU doesn't need to stop what its doing to service
a clock interrupt only to find that there was nothing to do.
As for applications of such a timer, I've worked on systems like
flight simulators where the deadline was on the order of 435us. Trying
to achieve that resolution with standard timers would be onerous
because I'd have to set the system HZ to something like 2298.8 Hz.
However, with a one shot timer like the HRTimer implementation, I could
just set up an interrupt to occur in 435 us from when I finished the
last simulation epoch. This results in a much lighter total loading to
the system as a whole while still allowing me to meet my deadline.
Don't think that just because you can get nanosecond resolution
(although, I think the implementation only talks about microsecond
res), that you're trying to actually use nanosecond-based timers. Most
applications I've encountered are quite happy with microsecond timing.
You can get that with HRtimers, but not likely with the standard Linux
timers.
HTH
Posted 4/22/2009
11:59 AM | 2
|
|
Here is another
way to look at it:
Non-HRT timers are expired by the kernel at the conclusion of every
tick. Because the size of the tick is on the order of milliseconds, it
can incur intolerable errors to applications that need tight control
over time. Assume your kernel has a tick size of 4 milliseconds. If
your application asks for a 1 millisecond interval at the beginning of
tick T0, the actual expiration does not happen until the conclusion of
tick T0. So while you expect an expiration after 1 millisecond (T0 + 1
ms), it is actually be returned to you 3 milliseconds late, at the
conclusion of the current tick (T0 + 4 ms). If you are trying to
periodically activate your application every 1 millisecond, non-HRT
timers are clearly insufficient.
HRT timers, in contrast, are not tied to the system tick. As
ptrmike said, they are tied directly to a hardware clock with
nanosecond resolution. It doesn't matter if your interval completes in
the middle of the tick -- your timer is expired immediately (and not at
the next tick boundary). Using the example above, if you ask for a 1
millisecond interval at the beginning of tick T0, it is returned to you
at time=T0 + 1 ms.
HRT timers are not only about measuring microsecond-level
intervals, but making the the measurement of intervals much more
accurate.
[Updated on 4/22/2009 12:51 PM]
[Updated on 4/22/2009 6:31 PM]
Posted 4/22/2009
12:51 PM | 2
|
|
Thanks for the
answers, yep I'm aware of how fine-grained the resolution can get
surely.
I recently implemented generic time (the framework written by
Thomas Gleixner and Ingo Molnár some time ago) for a new platform
(U300) and you specify a timesource and time event driver and provide
the necessary precision. (Documentation/timer/* in the kernel tree
gives background to this.)
If your hardware supports nanosecond resolution in timers you will
make it available all the way up into userspace, and you can actually
check the available resolution to by looking in /proc/timer_list in
recent kernels. If your timers have limited resolution the requests
from the API will be rounded to available resolution I believe.
What I was primarily after was a list of practical applications, and so
now I have one:
* Flight simulators
So what the HRTimers is used for is triggering events in userspace
applications, especially when your dealing with issues related to
automatic control:
http://en.wikipedia.org/wiki/Automatic_control
Now that means the list of possible applications utilizing these
very responsive control systems would include any user-space
applications for:
* Any interactive simulations and games
* Industrial automation including robotics
* Process industry applications (e.g. chemical processing)
* Various weapons including missiles
* Etc.
Posted 4/23/2009
2:28 AM |
|
|
