Javadoc description of System.nanoTime()

Miscellaneous Topics
#1

[quote]Returns the current value of the most precise available system timer, in nanoseconds.

This method can only be used to measure elapsed time and is not related to any other notion of system or wall-clock time. The value returned represents nanoseconds since some fixed but arbitrary time (perhaps in the future, so values may be negative). This method provides nanosecond precision, but not necessarily nanosecond accuracy. No guarantees are made about how frequently values change. Differences in successive calls that span greater than approximately 292 years (2^63 nanoseconds) will not accurately compute elapsed time due to numerical overflow.
[/quote]
look at the last bit. i mean, seriously, who is going to run a java app for 300 years ::slight_smile: a computer doesn’t even live that long, let alone stay up

#2

Even so, System.nanoTime() doesn’t work well on computers with dual core processors because it sometimes gets the time from the wrong core. That’s why System.nanoTime() is evil (as discussed in some other thread).

#3

but what if you use it in 1 thread? i suppose it will always get the time from the same core then?

#4

I wouldn’t be surprised if threads can get shunted from core to core without warning.

#5

Threads bounce from one core to another without warning and there’s no API call to set their affinity in Java yet. Maybe we’ll add one to LWJGL.

Cas :slight_smile:

#6

Here’s a pretty good blog about the issue: http://blogs.sun.com/dholmes/entry/inside_the_hotspot_vm_clocks
And here’s a Microsoft KB article: http://support.microsoft.com/kb/895980
It seems AMD has particular issues, however, it looks like it might have been fixed in Windows XP Service Pack 2:

[quote]For example Windows XP Service Pack 2 changed things to use the power management timer (PMTimer) rather than the processor timestamp-counter (TSC) due to problems with the TSC not being synchronized on different processors in SMP systems, and due the fact its frequency can vary (and hence it’s relationship to elapsed time) based on power-management settings.
[/quote]
Any Windows AMD users want to chime in with their experience?

#7

What about using NanoTimings if your data is loaded in RAM? Wouldn’t that be the best solution regarding the RAM running @ averaging 9ns, would it? And for disk storage, this wouldn’t be the case, averaging the HDD r/w access to 10ms…

#8

I never had a single problem using System.nanoTime() on dual core cpus. Neither AMD based nor Intel based.

#9

I’ve experienced various problems but we switched to timeGetTime in LWJGL-Win32 which is 1ms accurate and doesn’t fluctuate.

Cas :slight_smile:

#10

…but runs twice as fast on some machines and in some applications due to a VM bug? :wink:

#11

I’ve seen jumps and running double time on AMD dual, never on an intel.

Annoying timing artefacts in Java arn’t limited to checking the time tho, sleep() gets hit just the same.

Kev

#12

I think the problem with the LWJGL timer EgonOlsen is referring to (I’ve hit the same problem too) doesn’t have anything to do with the timing method itself but is totally due to a VM bug (which I haven’t been able to isolate though). I’ve never seen the same problem with System.currentTimeMillis.