Thanks for the speedy reply that was only posted like 10 minutes
ago :)

It seems then that on this machine the problem is unsolvable without
trying to simulate ~1ms in a busy method. Something which is not only
difficult, but really bad programming practice (busy methods are the
devil on many computers). Not cool. I see that the Thread class has a
sleep(millis) method. Is there any way to query how long a thread has
been sleeping (I dont see anything obvious in the api), and if so is
this any more accurate than the system clock?

-Numeron

Expanding on the example, I wrote the program below to collect
OS-specific timer resolution data, as described in Roedy's article:

<sscce>
public class MilliRes {

 public static void main(String[] args) {
   final int COUNT = 1000;
   long minMillis = Long.MAX_VALUE;
   long maxMillis = Long.MIN_VALUE;
   int sum = 0;
   int index = 0;
   while (index < COUNT) {
     final long start = System.currentTimeMillis();
     long delta = 0;
     while(delta < 1) {
       final long now = System.currentTimeMillis();
       delta = now - start;
     }
     minMillis = delta < minMillis ? delta : minMillis;
     maxMillis = delta > maxMillis ? delta : maxMillis;
     sum += delta;
     index++;
   }
   System.out.println(whichOS());
   System.out.println("min: " + minMillis + "ms");
   System.out.println("max: " + maxMillis + "ms");
   System.out.println("avg: " + (float) sum / COUNT + "ms");
 }
 
 private static String whichOS() {
   java.util.Properties p = System.getProperties();
   return p.getProperty("os.name")
      + ", " + p.getProperty("os.version")
      + ", " + p.getProperty("os.arch")
      + ", " + p.getProperty("java.version");
 }
}
</sscce>

This works with around 1600 nanosecond accuracy (.0016ms) on my
machine, thanks!

Roedy Green wrote:

Very helpful, thanks!

-Numeron