I’ve been digging through the kernel and data sheets for the bone trying to find out if it is capable of supporting 1000Hz Timer resolution and have been coming up dry. I was wondering if anyone has successfully ran a kernel with the timer resolution set to anything greater than 100Hz.
Reason im asking is I’ve been doing some work with the RT patch on the bone, and while i have gotten everything to work the latencies are still pretty high (Consistent, but high), and the only thing I haven’t been able to tweak is the timer resolution.
Regards,
Brandon
1000 Hz is possible. I run it on my Bones.
Change can look something like this:
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index f44d5a0..9469e1e 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1570,7 +1570,7 @@ config HZ
default OMAP_32K_TIMER_HZ if ARCH_OMAP && OMAP_32K_TIMER
default AT91_TIMER_HZ if ARCH_AT91
default SHMOBILE_TIMER_HZ if ARCH_SHMOBILE
- default 100
+ default 1000
config THUMB2_KERNEL
bool "Compile the kernel in Thumb-2 mode (EXP
Check that it's true, providing you don't have a tickless system
(dynamic ticks), by watching jiffies count:
root@bone1:~# cat /proc/interrupts | grep gp && cat /proc/uptime
68: 173922 INTC gp timer
174.69 156.66
root@bone1:~# cat /proc/interrupts | grep gp && cat /proc/uptime
68: 529386 INTC gp timer
529.80 511.74
The uptime and the gp timer _should_ count up at a factor of about
1:1000 with a 1000Hz kernel.
I believe you can't just set this in the .config or defconfig file. The
kernel build system will override it, thus the diff above which changes
that default. There's probably a "more right" way to accomplish this,
but this is the easy one.
Disabling dynamic ticks and upping the Hz to 1000 should increase your
power consumption, so just be aware of that. Sitting idle isn't really
sitting idle when you do this.
I don't believe you can push beyond about 1200 or 1500 Hz, so be aware
of that. I'm sure it's possible, but it'll require more than just
changing one line 
-Andrew
Thanks Andrew,
That would make sense with what I was seeing, I was setting the value in my .config but when I would boot the kernel it would still be running at 100Hz, I was trying to track down where along the line of kconfigs and make files I was losing my settings, but managed to get lost along the way.
Power consumption isn’t an issue for what I’m working on, just a timer resolution better than 1/100th of a second.
Thanks,
Brandon
Hello Brandon,
You can use OMAP2 built-in hardware timers if you want low-latency, interrupt-based, synchronous processes going on: I did use them to modulate light sources at 1 KHz.
The only drawback: you must be willing to do some kernel programming ;-).
Here’s a good starting point: an example is available at: http://www.kunen.org/uC/beagle/omap_dmtimer.html
Hope that helps,
Yves
2012/8/12 rbriggin <rbriggin@gmail.com>
Fantastic, Thanks for the pointer!
Thank you, Andrew & rbriggin!
Your discussion helps to tackle down my real-time problem indeed.
And this is a wild ghost that haunght me for weeks.
My realtime characteristics test shows that the signal (comes out from kernel to userspace process) delay is blow 60us under heavy payload, and the process shifting delay (worst) is 200us. But i am still wondering why my process can not stablely response in 10ms, Now i found the key is the time resolution.
By simply edit the arch/arm/Kconfig, I decrease worst-latency to half.
Now I push it to the limit (4096) to gain the best real-time perfomance.
I want to inquiry you How Higher Time Resolution Increases the realtime ability?
Any futher infomation to improve Linux’ RT ability?
2012-08-18