Re: nanosleep/usleep resolution?

Post #20,969 by a6l6e6x 12/10/01 11:37:01 PM Reply	Re: nanosleep/usleep resolution? For one thing you are measuring 1000 executions of the loop excluding usleep(). How long does it take if you comment out usleep()? Can you try single calls for 10 seconds, on each system? Alex Men never do evil so completely and cheerfully as when they do it from religious conviction. -- Blaise Pascal (1623-1662)
Post #20,989 by admin 12/11/01 9:15:48 AM Reply	Single calls are fine. Calls for < 10 ms should resolve at 10 ms. That's what the loop is testing. However, the Linux nanosleep sleeps for 20 ms instead. Anything over 20 ms sleeps for exactly that amount of time. On Solaris, anything under 10ms sleeps for 10ms, and anything over again for exactly that amount of time. Regards, -scott anderson
Post #21,005 by Steven A S 12/11/01 10:46:59 AM Reply	The only thing I see at least on the nanosleep function is the bug listed in the man pages: BUGS The current implementation of nanosleep is based on the normal kernel timer mechanism, which has a resolution of 1/HZ\\ s (i.e, 10\\ ms on Linux/i386 and 1\\ ms on Linux/Alpha). Therefore, nanosleep pauses always for at least the specified time, however it can take up to 10 ms longer than specified until the process becomes runnable again. For the same reason, the value returned in case of a delivered signal in rem is usually rounded to the next larger multiple of 1/HZ\\ s. As some applications require much more precise pauses (e.g., in order to control some time-critical hardware), nanosleep is also capable of short high-precision pauses. If the process is scheduled under a real-time policy like SCHED_FIFO or SCHED_RR , then pauses of up to 2\\ ms will be performed as busy waits with microsecond precision. But this doesn't seem to account for the 20 ms limitation you're seeing, except potentially on low end hardware. Could it be that the loop is increasing the delay up to 20 ms; but when the processor is getting longer delays, branch prediction is able to speed the loops? This is mearly speculation on my part, but I thought I'd throw it out there. ~~~)-Steven----* "I want you to remember that no bastard ever won a war by dying for his country. He won it by making the other poor dumb bastard die for his country..." General George S. Patton
Post #21,007 by admin 12/11/01 11:45:24 AM Reply	Yep, saw that. And basically what it's saying is that the Linux kernel has a 10ms timer loop on all i386 architectures, even my PIV chip. So this could be causing the behavior -- the nanosleep is waiting for the minimum (10ms) plus up to as much as another 10ms. I was just hoping someone could tell me how to get around that. :-) Regards, -scott anderson

Welcome to IWETHEY!