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 you got the point anyway ;) > > Ok, this makes sense - thanks. > > What confuses / confused me is that I have 4 combinations: > without-rt/with-rt X select/nanosleep; I first tried the > without-rt/select combination and right after that with-rt combinations > skipping the without-rt/nanosleep case. The first one was the one (the > only one) which gives me the 10ms average delay. And after your > explanations that fact bugs me even more. Actually, I just ran your prog on a ia32 -rt kernel, with highres, and using select, I get return times of less than 5ms. So this looks like a bug. On 2.6.17 vanilla, I also got under 5ms. But it might be ok for select to return early. I'm not sure on this one. But using nansleep never returned early on either system. > > But that is a side issue. The real problem is now: how do I get rid of > the multi-ms jitter? > 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. -- Steve - 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/