Hi Paul and Kelvin,
The information you provided is golden. It seems clear to me that what I'm
seeing is an artifact of the way that NT handles the Object wait() method.
This pattern:
> ...
>The Thread sleep(ms) and Object wait(ms) calls have very
> different results depending on the platform. I've included the output of
> some tests below which show the actual resolution of the sleep and wait
> events on NT and Solaris.
>
>
> NT
>
> ...
> 1000 calls to wait(1) in 15609 msec : 15.609 msec/sleep
> 1000 calls to wait(5) in 15625 msec : 15.625 msec/sleep
> 715 calls to wait(7) in 11172 msec : 15.625174825174826 msec/sleep
> 501 calls to wait(10) in 7828 msec : 15.624750499001996 msec/sleep
> 334 calls to wait(15) in 5219 msec : 15.625748502994012 msec/sleep
> 295 calls to wait(17) in 9218 msec : 31.247457627118646 msec/sleep
> 251 calls to wait(20) in 7844 msec : 31.250996015936256 msec/sleep
> 201 calls to wait(25) in 6281 msec : 31.248756218905474 msec/sleep
> 143 calls to wait(35) in 6704 msec : 46.88111888111888 msec/sleep
exactly mimics the pattern I see in my successive calls to processStimulus()
in Behaviors scheduled to WakeupOnElapsedTime(). This fits neatly with what
Kelvin wrote:
>A separate TimerThread is used for wakeupOnElapsedTime,
> the timer start when the user program invoke
>
> wakeupOn(WakeupCondition criteria)
>
> the request is then sent to the TimerThread for
> wait(waitTime);
Ba-da-bing!
I feel confident now in assuming that if I measure the system's
Object.wait() granularity before I set up my time_step, I'll be able to keep
control of the process.
Margo isn't going to like this, but there's a big difference between doing
somehing with understanding and casting around in the dark. I had feared
that I would have to measure it on the scenegraph itself.
> Solaris
> ...
> 1000 calls to wait(1) in 19969 msec : 19.969 msec/sleep
> 1000 calls to wait(5) in 19999 msec : 19.999 msec/sleep
> 715 calls to wait(7) in 14299 msec : 19.998601398601398 msec/sleep
> 501 calls to wait(10) in 10020 msec : 20.0 msec/sleep
> 334 calls to wait(15) in 6679 msec : 19.99700598802395 msec/sleep
> 295 calls to wait(17) in 5899 msec : 19.996610169491525 msec/sleep
> 251 calls to wait(20) in 7569 msec : 30.155378486055778 msec/sleep
> 201 calls to wait(25) in 6059 msec : 30.144278606965173 msec/sleep
> 143 calls to wait(35) in 5779 msec : 40.41258741258741 msec/sleep
>...
So it looks like I can set up time_step to 40 or 50 for Solaris.
> Another issue is the resolution of the System.currentTimeMillis() call
> which you might want to use to determine the accuracy of the sleep/wait.
> On NT the resolution of the timer is 15ms, on Solaris 1ms.
I sort of knew of this limitation, but I failed to consider it properly in
the measurements I reported. I suppose that it's dumb luck that the
granularity of the Object.wait() is the same as currentTimeMillis().
> So, we will continue to investigate this issue in terms of Java3D
implementation
> and the wider issue of accurate time in Java. In the meantime I suggest
> you use a seperate thread to perform your regular calculations
Hint? Do it in Mixed-Mode? In Canvas3D.preRender()?
> and use
> a behavior post to render the results.
Sorry. I don't understand this. What posts to what Behavior?
Actually, I didn't think of the existence of the 15 millisecond heartbeat as
a "problem." It was a huge "problem" until I started to understand its
nature and origin. I think that I'll be able to do a lot of what I want to
do on the scene graph within processStimulus(), as long as I know what that
heartbeat is.
> For accurate current time results you may want to look at the
> javax.media.TimeBase in JMF, again accuracy will vary with platform.
Sounds like I'll have to figure out how to use TimeBase to verify some of
this as I go along.
Thanks for all of your help.
Cheers,
Fred Klingener
Brock Engineering
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA3D-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
