title: Why is my System.nanoTime() broken?
body: <p>Myself and another developer on my time recently moved from a Core 2 Duo machine at work to a new Core 2 Quad 9505; both running Windows XP SP3 32-bit with JDK 1.6.0_18.</p>
  
  <p>Upon doing so, a couple of our automated unit tests for some timing/statistics/metrics aggregation code promptly started failing, due to what appear to be ridiculous values coming back from System.nanoTime().</p>
  
  <p>Test code that shows this behaviour, reliably, on my machine is:</p>
  
  <pre><code>import static org.junit.Assert.assertThat;
  
  import org.hamcrest.Matchers;
  import org.junit.Test;
  
  public class NanoTest {
  
    @Test
    public void testNanoTime() throws InterruptedException {
      final long sleepMillis = 5000;
  
      long nanosBefore = System.nanoTime();
      long millisBefore = System.currentTimeMillis();
  
      Thread.sleep(sleepMillis);
  
      long nanosTaken = System.nanoTime() - nanosBefore;
      long millisTaken = System.currentTimeMillis() - millisBefore;
  
      System.out.println("nanosTaken="+nanosTaken);
      System.out.println("millisTaken="+millisTaken);
  
      // Check it slept within 10% of requested time
      assertThat((double)millisTaken, Matchers.closeTo(sleepMillis, sleepMillis * 0.1));
      assertThat((double)nanosTaken, Matchers.closeTo(sleepMillis * 1000000, sleepMillis * 1000000 * 0.1));
    }
  
  }
  </code></pre>
  
  <p>Typical output:</p>
  
  <pre><code>millisTaken=5001
  nanosTaken=2243785148
  </code></pre>
  
  <p>Running it 100x yields nano results between 33% and 60% of the actual sleep time; usually around 40% though.</p>
  
  <p>I understand the weaknesses in accuracy of timers in Windows, and have read related threads like <a href="https://stackoverflow.com/questions/2688099/is-system-nanotime-consistent-across-threads">Is System.nanoTime() consistent across threads?</a>, however my understanding is that System.nanoTime() is intended for exactly the purpose we're using it :- measuring elapsed time; more accurately than currentTimeMillis().</p>
  
  <p>Does anyone know why it's returning such crazy results? Is this likely to be a hardware architecture problem (the only major thing that has changed is the CPU/Motherboard on this machine)? A problem with the Windows HAL with my current hardware? A JDK problem? Should I abandon nanoTime()? Should I log a bug somewhere, or any suggestions on how I could investigate further?</p>
  
  <p><b>UPDATE 19/07 03:15 UTC</b>: After trying finnw's test case below I did some more Googling, coming across entries such as <a href="http://bugs.java.com/view_bug.do?bug_id=6440250" rel="nofollow noreferrer">bugid:6440250</a>. It also reminded me of some other strange behaviour I noticed late Friday where pings were coming back negative. So I added <b>/usepmtimer</b> to my boot.ini and now all the tests behave as expected., and my pings are normal too.</p>
  
  <p>I'm a bit confused about why this was still an issue though; from my reading I thought TSC vs PMT issues were largely resolved in Windows XP SP3. Could it be because my machine was originally SP2, and was patched to SP3 rather than installed originally as SP3? I now also wonder whether I should be installing patches like the one at <a href="http://support.microsoft.com/kb/896256" rel="nofollow noreferrer">MS KB896256</a>. Maybe I should take this up with the corporate desktop build team?</p>