![]() | |||||||||||
Messages in this thread |
On 4/30/05, Olivier Croquette <ocroquette@free.fr> wrote: > Nish Aravamudan wrote: > > > Perhaps not discussed before, but definitely a known issue. Check out > > sys_nanosleep(), which adds an extra jiffy to the delay if there is > > going to be one. My patch, which uses human-time (or at least more so > > than currently), should not have issues like this. > > What would be then the most precise and reliable delaying possibility in > the present kernel? With Paulo's patch, everything should be ok with itimers again. The best you can get with HZ=1000 and sleeping is 1 millisecond (ideally). If you are ok with busy-waiting, then you get pretty arbitrary delays (usleep(), etc.). If you are willing to up HZ (10000 would give you 500 us resolution), things may get better. You could also try the HRT patches (not in mainline): http://sourceforge.net/projects/high-res-timers/ Finally, I posted my RFC for a new soft-timer subsystem based on John Stultz's timeofday rework last week. Good luck, Nish - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||
| Last update: 2005-05-02 08:11 [from the cache] ©2003-2008 | |||||||||||