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
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:
w
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
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 n
> 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 high-resolu
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 re
6 matches
Mail list logo
