Steven Rostedt wrote:
On Wed, 2005-08-17 at 19:38 -0700, Sundar Narayanaswamy wrote:
Hi,
I am trying to experiment using 2.6.12 kernel with the realtime-preempt
V0.7.51-38 patch to determine the kernel preemption latencies with the
CONFIG_PREEMPT_RT mode. The test program I wrote does the following on
a thread with highest priority (99) and SCHED_FIFO policy to simulate
a real time thread.
t1 = gettimeofday
nanosleep(for 3 ms)
t2 = gettimeofday
I was expecting to see the difference t2-t1 to be close to 3 ms. However,
the smallest difference I see is 4 milliseconds under no system load,
and the difference is as high as 25 milliseconds under moderate to
heavy system load (mostly performing disk I/O).
That version of Ingo's patch does not implement High-Resolution Timers.
Thomas worked on merging this into the latest RT patch. Without
high-res timers, the best you may ever get is 4ms. This is because
nanosleep is to guarantee _at_least_ 3 ms. So you have the following
situation:
0 1 2 3 4 (ms)
+---------------+---------------+----------------+---------------+--->
^ ^
| |
Start here 0+3 = 3 here we have the response
If we look at this in smaller units than ms, we started on 0.8ms and
responded at 3.2ms where we have 3.2 - 0.8 = 2.4 which is less than 3ms.
So since Ingo's patch doesn't increase the resolution of the timers from
a jiffy (which is currently 1ms) Linux is forced to add one more than
you need.
Based on the articles and the mails I read on this list, I understand that
worst case latencies of 1 ms (or less) should be possible using the RT
Preemption patch, but I am unable to get anything less than 4 millseconds
even with sleep times smaller than 3 ms. I am running the tests on a SBC
with a 1.4G Pentium M, 512M RAM, 1GB compact flash (using IDE).
I believe I have the high resolution timer working correctly, because if I
comment out the sleep line above t2-t1 is consistenly 0 or 1 microsecond.
I don't think you have the high res timer working, since there is no
high res timer in that kernel.
Following earlier discussions (in July) in this list, I tried to set kernel
configuration parameters like CONFIG_LATENCY_TRACE to get tracing/debug
information, but I didn't find these parameters in my .config file.
I appreciate your suggestions/insights into the situation and steps that I
should try to get more debug/tracing information that might help to understand
the cause of high latency.
It's not a high latency. It's doing exactly as it is suppose to, since
the nanosleep doesn't have high-res support (in that kernel). If you
really want to measure latency, you need to add a device or something
and see what the response time of an interrupt going off to the time a
thread is woken to respond to it. Now with Ingo's that is really fast.
Another way to do it is to set up a repeating timer. You _must_ read
back the timer to get the repeat time it is really using, and then
measure how well it does giving signals at these repeat times. FAR FAR
more than three lines of code...
--
George Anzinger [email protected]
HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |