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

Different platforms have different resolutions for System.currentTimeMillis(). You're INTERVAL of 25 milliseconds maybe small enough that you're getting the same value twice.

Also Thread.sleep() is not guarenteed to start the instant it's time is up. It's possible that the operating system scheduler and/or the Java scheduler may decide to do other things before it gets around to waking up your thread once it's ready. Under heavy load this will be more likely. Also your rendering work could be doing too much work to do in one interval.

You can: a) not worry about it, b) skip frames, or c) reduce the amount of work by lowering the quality when you're behind.

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:

System.currentTimeMillis() most likely uses the Real Time Clock (RTC) which is often not handled by the CPU itself but a daughter component. This is NOT the same as the systems internal clock cycles which are susceptible to skew based on load.

Intel platforms typically use a RTC that has a 19ms interval, so things which look use this will not show any difference between System.currentTimeMillis() calls within 19ms. That is to say that if you time two events that take less than 19ms, it is likely you will show zero time used.

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.

Thanks again for all the input. I've been away for awhile, but now starting looking at this again.

I ran the code I pasted above on two machines next to each other. Within minutes they are off from each in seconds!!

I figure from some of the advice I got that some believed I was coding a client, which is not the case. This is a server and it gets terrible when the clients and server get way out of sync, which is my problem.

Should I really be using System.currentTimeMillis() on the server? It behaves very differently between just two machines.... I'm getting differences beyond 10-50 ms, they now end up 1000's ms off each other with time.

We run ntp on all our severs at work (Linux or AIX) that way we know my servers have correct time and we can effectively compare logs. I don't know about Windows but on Linux/Unix NTP figures out clock drift and will make adjustments and it makes incremental corrections. Such that if your clock is only a few minutes off it will effectively speed up or slow down the clock until it is in sync again. That way you will never have a jump forward or backwards in time.

Now that J2SE 1.4.2 is officially released, I would suggest you use the new high resolution timer it provides.

The original query appears to relate to synchronization between two machines. The high resolution timer is not guaranteed to be synchronized at all.

The NTP clients in Windows 2000 and XP work much the same as the *nix equivalents, although by default they reference a Microsoft time server which may not be very local (>100ms round trip delay from here).

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

The timers in windows based systems are not accurate and other background processes will cause inaccuracies.

My experience of this is in profiling my Prolog program. (using SCI Prolog FYI)The docs say that you will never get super accurate results because windows does NOT count actual CPU cycles devoted to a process. So the timings a estimates at best. (Making sure all your background processes are switched off will help)Linux, of course, will return very accurate results.This explains why Jeff is getting good results, you wont/can't on your windows systems.

This is very frustrating in my case because I will be using profiling to estimate execution times on a 600 machine cluster that has a mixture of XP and Linux boxes. Bugger.

--More than likely I have offended you with the above post. Don't feel bad, we are often upset by things we are too damned stupid to understand.

The timers in windows based systems are not accurate and other background processes will cause inaccuracies....The docs say that you will never get super accurate results because windows does NOT count actual CPU cycles devoted to a process. So the timings a estimates at best. (Making sure all your background processes are switched off will help)

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.

My experience of this is in profiling my Prolog program. (using SCI Prolog FYI)The docs say that you will never get super accurate results because windows does NOT count actual CPU cycles devoted to a process.

Windows NT, 2000, XP do count CPU time for each thread and process. Windows 9X and ME do not. The resolution is limited to that of the system clock (usually 10ms on single processor machines and 15.625ms on multiprocessors).

However as someone else has pointed out real time rather than CPU time is the subject of this thread.

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.

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

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org