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