Re: Accurate CPU timing on Windows -- How?

Michele Mazzucco wrote:

Jess,

I'm saying (a), but it's not a windows only problem. It applies to linux
as well (I think it applies to all non-realtime os).
  

Actually a little experimentation shows (a) is *not* the case.

Try:

public class Test
{
  public static void main( String args[] )
    throws Exception
  {
    for ( int ii = 0; ii < 20; ++ii )
    {
      final long start = System.nanoTime();
      Thread.sleep( 3L );
      final long end = System.nanoTime();
      System.out.println( (double) ( end - start ) / 1.0e9 );
    }
  }
}

When running this, I get:

0.002209499
0.003041727
0.002880813
0.002905955
0.003513295
0.002158934
0.00289562
0.002910706
0.002923277
0.002881372
0.002910984
0.002908471
0.002911264
0.002274591
0.003108216
0.002893664
0.002867683
0.002905676
0.002910984
0.002916013

That is clearly *far* more accurate than using System.currentTimeMillis() [and switching the conversion factor], where I get:

0.0
0.0
0.01
0.0
0.0
0.01
0.0
0.0
0.01
0.0
0.0
0.01
0.0
0.0
0.0
0.01
0.0
0.0
0.01
0.0

[The average of these does actually give exactly 0.003 seconds, which is correct.]

This shows that either the issue is (b) or Sun's System.currentTimeMillis() is unnecessarily inaccurate (though this may well impact more than just Windows).

--
Jess Holle

On Thu, 2007-07-19 at 06:35 -0500, Jess Holle wrote:
  

Michele Mazzucco wrote:
    

On Wed, 2007-07-18 at 15:51 -0500, Jess Holle wrote:
      

      * On Windows [at least], System.currentTimeMillis()'s resolution
        is not milliseconds but rather about 0.01 seconds.
              * We could use System.nanoTime() instead, but it appears
                that acquiring this takes a bit more time.  Moreover,
                for the usages in question millisecond accuracy is
                sufficient, but 0.01 seconds is not always.
        

Jess,

this is a kernel issue (kernel precision is typically 10/15 ms), it's
not related with java.
      

So are you saying that System.nanoTime() is:
     a. No more accurate than System.currentTimeMillis() on Windows
        *or*
     b. Is sufficiently costly that Sun doesn't want to implement
        System.currentTimeMillis() via System.nanoTime()'s internals?
Clearly (b) is possible in that one can compute an offset by examining
System.currentTimeMillis() and System.nanoTime() on startup, doing all
timing via nanoTime() and then using the startup numbers to convert
from nanoTime() results to currentTimeMillis() results.  I do it in a
few places to avoid having to obtain both types of times when I
already have nanoTime() for some reason.  I have to assume that (b) is
more costly, though -- from my own results.

While all this is annoying the bigger issue is thread CPU time...

--
Jess Holle

=========================================================================== For information on the Java Management extensions (JMX), please visit our home page at http://java.sun.com/products/JavaManagement/ The JMX-FORUM archives are accessible at http://archives.java.sun.com To unsubscribe, send email to listserv@... and include in the body of the message "signoff JMX-FORUM". For general help, send email to listserv@... and include in the body of the message "help".