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
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:
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()
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:
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
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:
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
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
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
12 matches
Mail list logo
