How reliable is System.currentTimeMillis()? Is it possible that the currentTimeMillis() starts falling behind if the computer has a heavy workload? I'm using it to time frames per second and it seems to behave oddly sometimes...

Here's the code. Let me know if it doesn't make sense.

     private static boolean   engineRunning = true;
     private static long startTime;
     private static int  SLEEP_TIME= 0;
     private static final int INTERVAL= 25;
     public static int CURR_FRAME = 0;

     public void run () {
           startTime=System.currentTimeMillis();
           while (engineRunning) {
                 SLEEP_TIME=(int) (startTime+(CURR_FRAME*INTERVAL)-System.currentTimeMillis());

                 if (SLEEP_TIME<0){
                       // scheduler is behind! This will cause huge problems!
                       System.out.println("Scheduler is behind:"+SLEEP_TIME+" ms. ("+(System.currentTimeMillis()-startTime)+")");      
                 }else{
                       try {sleep(SLEEP_TIME);}
                       catch(InterruptedException e) {}
                 }

                 // new frame
                 CURR_FRAME++;

                 // process events of frame etc. etc.

Thanks for the input. I've also noticed that thread.sleep() can +-5 ms. Is this the conventional way to code a Scheduler or are there better alternatives for keeping track of frames?

What works the best (it seems) is to just generate as many frames per second as possible and let the VSync smooth everything. Of course, this is a problem if you can't push that many FPS for some reason. I just wrote a timer to help with this problem. Check out the discussions at:

http://www.JavaGaming.org/cgi-bin/JGOForums/YaBB.cgi?board=share;action=display;num=1048008212

and

http://forum.java.sun.com/thread.jsp?forum=406&thread=373032&tstart=0&trange=15

Partially correct. The Intel timer chip beats about once every 19.2 ms (as you said) and is used to keep the system clock running. The one trick here is that the chip can be reprogrammed. Every DOS video game I ever knew of reset it to align with the VSync. And modern day OSes reset the clock to whatever the heck they feel like. Under Windows 98 it's something like 50 ms, while Windows 2000 & XP set it to 10 ms. The *nixes don't screw around. They tick every millisecond. Try downloading the timer code I wrote and you'll be able to measure the timer resolution for various systems.

Oh yeah.. another thing.. if you really need to use the System.currentTimeMillis(), you really should capture 10-12 frames and divide the result by 12 to get a average time.

Btw is there a way to analyze the system clock on a computer and get it tuned? I got no way of telling if the clock is healthy...

Is the "Perf" class actually part of the officially exposed API now, or is it still hidden?

Kev

Anything in com.sun.* is, by definition, specific to the sun VM (and anyone who copies it) but not part of the standard.

I have every hope though that this functionality will move over to be part of the standard by 1.5

JK

aikarele, I tried the code you submitted that uses sun.misc.Perf

The hiResTimer.currentTimeMillis() method goes haywire on one of my computers. It ranges from -540000 to 946000 making huge leaps between ticks. I'm not sure if it proves the computer is sick, but lets say it is... should I be changing the whole motherboard or is there a simple way to change the hardware clock...

Background processes have no effect on hardware timers, I think you are confused.  At worst the timer would lag if hardware interrupts were missed because of some other high priority code locking out the ISR for too long.

Remember we are measuring REAL time, not the amount of time that our process gets the CPU.

Windows system time is initialised from the hardware clock at boot but subsequently runs independently. It can and does drift if interrupts are missed (these days rather rare). It has also been found to drift if the clock period is changed too often (a side effect of using Thread.sleep(1) --- there is a bug in the bug parade relating to this. http://developer.java.sun.com/developer/bugParade/bugs/4500388.html

This drift may be corrected if an NTP client is in use.