Erratic timer on AMD64-X2 system

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Run Milpa game demo
2. Observe erratic motion/animation.

What is the expected output? What do you see instead?

Expected smooth motion.

What version of the product are you using? On what operating system?
- AMD Athlon 64 X2 Dual system, running Windows XP
- Java build 1.6.0_05-b13

Please provide any additional information below.

- There is a bug with the System.NanoTime implementation on AMD64 X2
machines where the two processors are not completely synchronized, and so
two subsequent calls to NanoTime could return a negative delta. That's
probably what's happening here. I'd be glad to test out any debug
builds/solutions you might come up with, if you're interested in working on
fixing this issue.

Thanks for the excellent framework!

Original issue reported on code.google.com by will.jor...@gmail.com on 3 Apr 2008 at 12:28

[GoogleCodeExporter]

Thanks for posting the issue!

I'll take a look at a possible fix, but it's a difficult problem to solve.

From what I understand this bug has been fixed in Vista.

If you're feeling brave enough to edit system files, there's a client-side fix 
you can do here:
http://support.microsoft.com/kb/895980
It involves modifying the Boot.ini file to use the /usepmtimer switch.

Original comment by brack...@gmail.com on 3 Apr 2008 at 12:48

[GoogleCodeExporter]

Yeah, I know about the client-side fix but that doesn't help much with 
deploying the
framework to users who don't :)

If you are willing to try and put in a specific fix, there are two approaches I 
could
see being potentially helpful in the general case:

1. Compensate for the buggy nanoTime implementation by adding an estimate 
window (to
prune excessively large and/or negative deltas)

2. Add a check/detection for severe timer bugs in the NanoTimer (such as a 
negative
delta), and fall back to the estimating SystemTimer if detected.

Original comment by will.jor...@gmail.com on 3 Apr 2008 at 1:57

[GoogleCodeExporter]

I have a potential fix, and if it works on your machine I'll include in the 
core. The Easing example should be a 
good test. 
Old:
http://www.interactivepulp.com/pulpcore/easing/
New:
http://www.interactivepulp.com/pulpcore/easingfix/

Original comment by brack...@gmail.com on 5 Apr 2008 at 9:52

[GoogleCodeExporter]

Thanks for putting up a fix to try. I'm playing around with it right now on the
system with the bug (it's my work PC so I had to wait till this morning), and it
looks like it's all running smoothly now. The strange thing, however, is that 
the old
version runs fine too, and so does the Milpa game on which I originally 
observed the bug!

I'm going to run some simple timer tests to see it's still behaving as it used 
to on
my system, perhaps I inadvertently patched it somehow... Or, could it be 
possible
that your patch might have been applied to all of the applets somehow?

Original comment by will.jor...@gmail.com on 7 Apr 2008 at 7:19

[GoogleCodeExporter]

Nope, the fix should only apply to the "easingfix" example.

It might be the nanotime bug (CPU ticks out of sync) only happens in some 
situations - total guess here, but 
these might be factors in the CPU ticks being out of sync: how long the PC has 
been running, how long the VM 
has been running, and what other processes are currently running. If you do end 
up reproducing the bug, let me 
know.

Original comment by brack...@gmail.com on 7 Apr 2008 at 7:32

[GoogleCodeExporter]

Good news! The stars were aligned to bring my processor timers out of sync this
morning on my machine (maybe it was because I left it on overnight?), so I was 
able
to reproduce the bug again. Looks like the "easingfix" example solves the 
problem!

Original comment by will.jor...@gmail.com on 9 Apr 2008 at 6:40

[GoogleCodeExporter]

Great! I checked in the fix into SVN. Let me know if there are any more 
problems.

Original comment by brack...@gmail.com on 9 Apr 2008 at 7:06

• Changed state: Fixed