On Wed, Jun 11, 2008 at 08:52:24AM +0200, Michael Kerrisk wrote: [...] > > I think it should be worth mentionning that since 2.6.16, on > > some architectures, the kernel can be configured with high > > resolution timers which makes nanosleep(2) a lot more accurate > > and voids the first comment above. [...] > Thanks for your note. Can you provide some further details -- for > example, can you tell me any of the following: > which architectures? > what config options are required? > what determines the accuracy that can be achieved with HR timers? [...]
Hi Michael, sorry, I'm not a kernel developper, so I know very little about it. I only observed that usleep() became a lot more accurate since 2.6.16. While usleep(1) was sleeping for about 10ms before (to the next tick), it now sleeps for about 1µs as requested when tried on x86 (usleep(3) calls nanosleep(2)). Last time I checked ARCH=ppc didn't have such support but ARCH=powerpc did. I don't know about the other architectures, but that would be a matter of checking the Kconfigs. It's enabled with CONFIG_HIGH_RES_TIMERS which itself depends on architecture specific options. More information can be found in Documentation/hrtimers/hrtimers.txt in the kernel sources which says: The code was successfully compiled for the following platforms: i386, x86_64, ARM, PPC, PPC64, IA64 The code was run-tested on the following platforms: i386(UP/SMP), x86_64(UP/SMP), ARM, PPC hrtimers were also integrated into the -rt tree, along with a hrtimers-based high-resolution clock implementation, so the hrtimers code got a healthy amount of testing and use in practice. regards, Stéphane -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
