Timer Resolution

[kevglass]

I'm finding that the Sys.getTime() timer isn't actually giving me 1ms resolution on some windows platforms. I'm using the following test case (which of course could be in error ):

import org.lwjgl.Sys;

public class TimerTest {
   public static void main(String argv[]) {
      long oldTime = 0;
      
      while (true) {
         long time = (Sys.getTime() * 1000) / Sys.getTimerResolution();
         if (time != oldTime) {
            System.out.println(System.currentTimeMillis()+" : "+time+" (delta = "+(time-oldTime)+")");
            oldTime = time;
         }
      }
   }
}

I think it should be only showing deltas of 1ms, but on some windows systems (3 on XP that I've had so far) I get output similar to:

1213123628999 : 1019517778 (delta = 1)
1213123628999 : 1019517780 (delta = 2)
1213123629015 : 1019517796 (delta = 16)
1213123629031 : 1019517811 (delta = 15)
1213123629046 : 1019517827 (delta = 16)
1213123629062 : 1019517843 (delta = 16)
1213123629078 : 1019517859 (delta = 16)
1213123629093 : 1019517875 (delta = 16)
1213123629093 : 1019517876 (delta = 1)
1213123629109 : 1019517878 (delta = 2)
1213123629124 : 1019517893 (delta = 15)
1213123629140 : 1019517909 (delta = 16)
1213123629156 : 1019517924 (delta = 15)
1213123629156 : 1019517925 (delta = 1)
1213123629171 : 1019517941 (delta = 16)
1213123629171 : 1019517942 (delta = 1)
1213123629171 : 1019517943 (delta = 1)
1213123629171 : 1019517944 (delta = 1)
1213123629203 : 1019517975 (delta = 31)
1213123629203 : 1019517976 (delta = 1)
1213123629203 : 1019517977 (delta = 1)
1213123629218 : 1019517993 (delta = 16)
1213123629218 : 1019517994 (delta = 1)
1213123629218 : 1019517995 (delta = 1)
1213123629234 : 1019518010 (delta = 15)
1213123629234 : 1019518011 (delta = 1)
1213123629234 : 1019518012 (delta = 1)
1213123629234 : 1019518013 (delta = 1)

Any ideas why we're getting those peaks? I am getting the correct result on at least one XP machine. As an interesting aside the resolution is actually fixed by playing an OpenAL source (presumably the OpenAL lib is doing some resolution setting on the timer or something).

Thanks for any help,

Kev

[Fool Running]

Does the same thing happen if you remove the * 1000 / Sys.getTimerResolution() from the time since it will be the same without it anyways?
Just wondering about some weird overflow or something strange like that (even though its unlikely).

[kevglass]

Yep, tried that. getTime() is returning the same values for a bunch of calls and then leaping.

Kev

[tomb]

I had problem with the timer 3 years ago. Made a test that I posted on javagaming:
http://www.javagaming.org/index.php/topic,8541.0.html

[wolf_m]

I'm guessing this is purely OS-related.

Maybe it is related to thread priorities on Windows. You idle more cycles than intended because you don't have a high enough priority. The bumpy outcome could be related to your process environment.

Have you tried upping the thread priority of the executing VM in the task manager? Does it have an effect?

What are the differences in hardware and software on the machines?

Could you try a similar experiment with two threads that constantly throw the ball to each other? Threads are native on Windows, so that should give you a priority advantage.

[kevglass]

There's nothing else running on these machines (at least nothing user). It's stranger that I've not seen the issue before - I wondered if it could be something to do with the upgrade from 1.0 to 2.0, but yet to get a chance to try a lwjgl 1.0 test case on one of the effected machines.

Kev

[princec]

Hm, I thought LWJGL was using the nice and reliably accurate timeGetTime multimedia function on windows, with a timeBeginTime or whatever it was to ensure that accuracy was 1ms?

Cas

[kevglass]

It is

Still seeing machines where it doesn't work tho.

Kev