nanoSleep

[clebert.suconic]

I'm writing a native call to nanoSleep.

As we have talked over IRC, I'm measuring the precision, and the weight of JNI calls.

I have made a bunch of tests:

My conclusion is that it is close enough for 20K.


Follows a table:



Time IntervalNumber Of LoopsTime Taken


01,000,00017 milliseconds


1000 nanosecond1,000,0003856 milliseconds


20 K nanosecond1,000,00023312 milliseconds

[timfox]

Ok, so how about we plump for 15K nano sleep, which should give us about 20K actual nano seconds, i.e. 20 microseconds...

[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.

[clebert.suconic]

Phillip Thurmond sent me this link:


http://fixunix.com/unix/552033-problem-nanosleep.html

[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.

[timfox]

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.

[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.