-
1. Re: nanoSleep
timfox Jun 4, 2009 2:00 PM (in response to clebert.suconic)Ok, so how about we plump for 15K nano sleep, which should give us about 20K actual nano seconds, i.e. 20 microseconds...
-
2. Re: nanoSleep
clebert.suconic Jun 4, 2009 6:35 PM (in response to clebert.suconic)We will need to go back to System.nanoTime().
there are some kernel versions that don't play well with timing. nanosleep, usleep or any other native sleep has ticking problems.
Or maybe.. we keep native-timers, and let the user decide on flush-on-sync. That would save some cpu cycles. -
3. Re: nanoSleep
clebert.suconic Jun 4, 2009 6:36 PM (in response to clebert.suconic)Phillip Thurmond sent me this link:
http://fixunix.com/unix/552033-problem-nanosleep.html -
4. Re: nanoSleep
clebert.suconic Jun 5, 2009 1:31 AM (in response to clebert.suconic)The minimal resolution I have found on Rhel is 1 millisecond. No matter what you do. (No wonder Java has decided to not implement System.sleep for micro and nanosleep yet). That's a mess when you consider multiple platform even among different kernel versions.
-
5. Re: nanoSleep
timfox Jun 5, 2009 5:27 AM (in response to clebert.suconic)"clebert.suconic@jboss.com" wrote:
The minimal resolution I have found on Rhel is 1 millisecond. No matter what you do. (No wonder Java has decided to not implement System.sleep for micro and nanosleep yet). That's a mess when you consider multiple platform even among different kernel versions.
Clebert, this does not make sense.
Earlier in this thread you posted results that showed 1000000 nanosleeps taking in total 17, 3856 milliseconds, which is way less than 1 ms, so your statement is completely contradictory to your results. -
6. Re: nanoSleep
clebert.suconic Jun 5, 2009 7:59 AM (in response to clebert.suconic)As I said... there are some kernel versions that don't play well with timing.
depending on the Linux version, this will play differently, and the kernel version on RHEL (our performance lab) has the bug on the kernel in place.