[EMAIL PROTECTED]:~$ uname -r
2.6.19.1-rt15_00
And I'm totally thrilled since this is the first -rt kernel that I've
tried and been able to boot since .16-rt29. Yay!
[EMAIL PROTECTED]:~$ zcat /proc/config.gz | egrep "HZ.*=y"
CONFIG_HZ_1000=y
100 revs; min: 5008 max: 5034 avg: 5015
100 revs;
On Fri, 15 Dec 2006, Ingo Molnar wrote:
>
> so these results look pretty normal to me.
Ingo, Did you run this with high res turned off? That will simulate his
scenerio more so.
> Modified code attached below.
> (Change the '#if 1' to '#if 0' to get the select() measurement.)
Your code is
* tike64 <[EMAIL PROTECTED]> wrote:
> I made my test code visible if you want to take a look: www dot
> riihineva dot no-ip dot org uphill public uphill test-rt.c
on x86, with nanosleep i get:
# ./test-rt
100 revs; min: 5026 max: 5099 avg: 5062
100 revs; min: 5031 max: 5105 avg: 5065
100
* tike64 [EMAIL PROTECTED] wrote:
I made my test code visible if you want to take a look: www dot
riihineva dot no-ip dot org uphill public uphill test-rt.c
on x86, with nanosleep i get:
# ./test-rt
100 revs; min: 5026 max: 5099 avg: 5062
100 revs; min: 5031 max: 5105 avg: 5065
100 revs;
On Fri, 15 Dec 2006, Ingo Molnar wrote:
so these results look pretty normal to me.
Ingo, Did you run this with high res turned off? That will simulate his
scenerio more so.
Modified code attached below.
(Change the '#if 1' to '#if 0' to get the select() measurement.)
Your code is almost
[EMAIL PROTECTED]:~$ uname -r
2.6.19.1-rt15_00
And I'm totally thrilled since this is the first -rt kernel that I've
tried and been able to boot since .16-rt29. Yay!
[EMAIL PROTECTED]:~$ zcat /proc/config.gz | egrep HZ.*=y
CONFIG_HZ_1000=y
100 revs; min: 5008 max: 5034 avg: 5015
100 revs;
Steven Rostedt <[EMAIL PROTECTED]> wrote:
> So you got a big jitter using nanosleep??? If that's the case, could
> you post the times you got. I'll also boot a kernel with the latest
> -rt patch, without highres compiled, and see if I can reproduce the
> same on x86.
You're very kind! Here you
On Thu, 14 Dec 2006, tike64 wrote:
> Steven Rostedt <[EMAIL PROTECTED]> wrote:
> > ...
> > it's ok for the timer to be a little over, but it must never be a
> > little under.
> > ...
> > So we make sure the timer goes off in (n+1) ms, and not just (n).
Oops, that should have read (n+1) 10ms, or
Steven Rostedt <[EMAIL PROTECTED]> wrote:
> ...
> it's ok for the timer to be a little over, but it must never be a
> little under.
> ...
> So we make sure the timer goes off in (n+1) ms, and not just (n).
Ok, this makes sense - thanks.
What confuses / confused me is that I have 4 combinations:
On Thu, 14 Dec 2006, tike64 wrote:
> Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > tike64 <[EMAIL PROTECTED]> wrote:
> > > Ok, understood; I tried this:
> > >
> > > t = raw_timer();
> > > ts.tv_nsec = 500;
> > > ts.tv_sec = 0;
> > > nanosleep(, 0);
> > > t = raw_timer() - t;
> > >
>
Ingo Molnar <[EMAIL PROTECTED]> wrote:
> tike64 <[EMAIL PROTECTED]> wrote:
> > Ok, understood; I tried this:
> >
> > t = raw_timer();
> > ts.tv_nsec = 500;
> > ts.tv_sec = 0;
> > nanosleep(, 0);
> > t = raw_timer() - t;
> >
> > It is better but I still see 8ms occasional
* tike64 <[EMAIL PROTECTED]> wrote:
> Steven Rostedt <[EMAIL PROTECTED]> wrote:
> > Also, have you tried this with a nanosleep instead of a select.
> > Select's timeout is just that, a timeout. It's not suppose to be
> > accurate, as long as it doesn't expire early. The reason I state
> > this,
Steven Rostedt [EMAIL PROTECTED] wrote:
So you got a big jitter using nanosleep??? If that's the case, could
you post the times you got. I'll also boot a kernel with the latest
-rt patch, without highres compiled, and see if I can reproduce the
same on x86.
You're very kind! Here you go:
* tike64 [EMAIL PROTECTED] wrote:
Steven Rostedt [EMAIL PROTECTED] wrote:
Also, have you tried this with a nanosleep instead of a select.
Select's timeout is just that, a timeout. It's not suppose to be
accurate, as long as it doesn't expire early. The reason I state
this, is that
Ingo Molnar [EMAIL PROTECTED] wrote:
tike64 [EMAIL PROTECTED] wrote:
Ok, understood; I tried this:
t = raw_timer();
ts.tv_nsec = 500;
ts.tv_sec = 0;
nanosleep(ts, 0);
t = raw_timer() - t;
It is better but I still see 8ms occasional delays when listing
On Thu, 14 Dec 2006, tike64 wrote:
Ingo Molnar [EMAIL PROTECTED] wrote:
tike64 [EMAIL PROTECTED] wrote:
Ok, understood; I tried this:
t = raw_timer();
ts.tv_nsec = 500;
ts.tv_sec = 0;
nanosleep(ts, 0);
t = raw_timer() - t;
It is better but I still see
Steven Rostedt [EMAIL PROTECTED] wrote:
...
it's ok for the timer to be a little over, but it must never be a
little under.
...
So we make sure the timer goes off in (n+1) ms, and not just (n).
Ok, this makes sense - thanks.
What confuses / confused me is that I have 4 combinations:
On Thu, 14 Dec 2006, tike64 wrote:
Steven Rostedt [EMAIL PROTECTED] wrote:
...
it's ok for the timer to be a little over, but it must never be a
little under.
...
So we make sure the timer goes off in (n+1) ms, and not just (n).
Oops, that should have read (n+1) 10ms, or +1 res. But
Steven Rostedt <[EMAIL PROTECTED]> wrote:
> Also, have you tried this with a nanosleep instead of a select.
> Select's timeout is just that, a timeout. It's not suppose to be
> accurate, as long as it doesn't expire early. The reason I state
> this, is that select uses a different mechanism than
For -rt issues, please CC Ingo Molnar, and for High Res issues, please
CC Thomas Gleixner.
On Fri, 2006-12-01 at 01:07 -0800, tike64 wrote:
> > Hi,
> >
> > Without the support of High Resolution Timer
> > supported, the timer resolution wouldn't change.
>
> Ok, I understand that. I was not
For -rt issues, please CC Ingo Molnar, and for High Res issues, please
CC Thomas Gleixner.
On Fri, 2006-12-01 at 01:07 -0800, tike64 wrote:
Hi,
Without the support of High Resolution Timer
supported, the timer resolution wouldn't change.
Ok, I understand that. I was not expecting
Steven Rostedt [EMAIL PROTECTED] wrote:
Also, have you tried this with a nanosleep instead of a select.
Select's timeout is just that, a timeout. It's not suppose to be
accurate, as long as it doesn't expire early. The reason I state
this, is that select uses a different mechanism than
> Hi,
>
> Without the support of High Resolution Timer
> supported, the timer resolution wouldn't change.
Ok, I understand that. I was not expecting more
resolution. I expected only that I would get more
precise 10ms delays. What confuses me is that the
delays roughly doubled.
> With
Hi,
Without the support of High Resolution Timer
supported, the timer resolution wouldn't change.
Ok, I understand that. I was not expecting more
resolution. I expected only that I would get more
precise 10ms delays. What confuses me is that the
delays roughly doubled.
With
: tike64 <[EMAIL PROTECTED]>
Subject: realtime-preempt and arm
Date: Wed, 29 Nov 2006 00:57:05 -0800 (PST)
> Hi all,
>
> I'm trying the realtime-preempt patch-2.6.18-rt6 on
> lh7a400 arm system with little success. In a test
> program I try 5 ms timeout with select() but get 20
: tike64 [EMAIL PROTECTED]
Subject: realtime-preempt and arm
Date: Wed, 29 Nov 2006 00:57:05 -0800 (PST)
Hi all,
I'm trying the realtime-preempt patch-2.6.18-rt6 on
lh7a400 arm system with little success. In a test
program I try 5 ms timeout with select() but get 20 ms
avg or 26 ms max. When
Hi all,
I'm trying the realtime-preempt patch-2.6.18-rt6 on
lh7a400 arm system with little success. In a test
program I try 5 ms timeout with select() but get 20 ms
avg or 26 ms max. When the framebuffer scrolls, the
max delay goes up to 59 ms. With a vanilla kernel I
get 10 ms (because of tick
Hi all,
I'm trying the realtime-preempt patch-2.6.18-rt6 on
lh7a400 arm system with little success. In a test
program I try 5 ms timeout with select() but get 20 ms
avg or 26 ms max. When the framebuffer scrolls, the
max delay goes up to 59 ms. With a vanilla kernel I
get 10 ms (because of tick
28 matches
Mail list logo
