Schedule timing problem... 1000 ms. != 1 sec.
by Morphonix LLC · in Torque Game Engine · 04/01/2005 (3:18 pm) · 13 replies
I am using "schedule" to coordinate the playback of a lot of media,
(e.g. animation, audio, pre-rendered movies, etc.) I was noticing some
timing issues so I wrote the following script funcion to check this out.
I call this function from the console as follows:
dbgTime(100);
or
dbgTime(1000);
or
dbgTime(60000);
as long as 60000 (60 seconds) can be evenly divided by the parameter
(which is the callback interval)
I time the function with a stopwatch, to see what the engine thinks 60 seconds is.
-------
On my machine, this took approx 75 sec, regardless of the callback interval.
On the rest of the machines in our office that I had access to, it took about 65 sec.
The good news for me was that the timing wasn't drifting due to the function re-scheduling
itself (which was what I set up the test to discover)
However, I am fairly dismayed at the timing discrepency.
Has anyone else seen this, and is there a way to calibrate the timing?
(e.g. animation, audio, pre-rendered movies, etc.) I was noticing some
timing issues so I wrote the following script funcion to check this out.
function dbgTime(%interval,%total)
{
if (%total $= "")
{
$dbgTiming = true;
%total = 0;
}
%display = mFloor(%total / 1000);
if (%display == (%total / 1000))
echo("seconds: "@%display);
if (%display >= 60)
{
echo("STOP!!!");
return;
}
%total += %interval;
schedule(%interval,0,dbgTime,%interval,%total);
}I call this function from the console as follows:
dbgTime(100);
or
dbgTime(1000);
or
dbgTime(60000);
as long as 60000 (60 seconds) can be evenly divided by the parameter
(which is the callback interval)
I time the function with a stopwatch, to see what the engine thinks 60 seconds is.
-------
On my machine, this took approx 75 sec, regardless of the callback interval.
On the rest of the machines in our office that I had access to, it took about 65 sec.
The good news for me was that the timing wasn't drifting due to the function re-scheduling
itself (which was what I set up the test to discover)
However, I am fairly dismayed at the timing discrepency.
Has anyone else seen this, and is there a way to calibrate the timing?
About the author
#2
04/01/2005 (4:21 pm)
Worked out to pretty much exactly 60 seconds for dbgTime(60); for me.
#3
04/01/2005 (5:11 pm)
I did dbgTime(100); and the whole process pretty much exactly took 60 seconds for me too.
#4
this is much better, but is still off a fair bit.)
I'm not really looking for millisecond accuracy, This discrepency is 4 or 5
orders of magnitude greater that ms when we are timing in the range of
5 to 60 seconds. one machine is of by 25% and the others are off by ~10%.
(is this still in the ballpark? I'm not certain)
(Note edited.... because the large discrepency only occurs on a custom
version of Torque, I am removed the dire warnings. ;-)
Because the difference is so large and consistent, I was hoping someone
has already dealt with this issue, or at least noticed. I am using
(pretty much) the 1.3 release, and my machines are nothing very special
(one Dell, one HP, and a couple of eMachines).
This could be (a significant issue) [edit: an issue] for people who rely on
schedule to be within a couple of seconds of accuracy for their complex
animation sequences to play as intended.
If anyone has had to calibrate the timing, or has any idea how, I would be
very interested in hearing how they did it. My plate is pretty full (I will be
crunching for quite a while it seems) so I was hoping that this was a well
known issue if you know what I mean ;-)
(Note added... still interested in calibration...)
04/02/2005 (7:35 pm)
(Note added... with the clean 1.3 Torque I am getting ~65 sec for 60000 ms.this is much better, but is still off a fair bit.)
I'm not really looking for millisecond accuracy, This discrepency is 4 or 5
orders of magnitude greater that ms when we are timing in the range of
5 to 60 seconds. one machine is of by 25% and the others are off by ~10%.
(is this still in the ballpark? I'm not certain)
(Note edited.... because the large discrepency only occurs on a custom
version of Torque, I am removed the dire warnings. ;-)
Because the difference is so large and consistent, I was hoping someone
has already dealt with this issue, or at least noticed. I am using
(pretty much) the 1.3 release, and my machines are nothing very special
(one Dell, one HP, and a couple of eMachines).
This could be (a significant issue) [edit: an issue] for people who rely on
schedule to be within a couple of seconds of accuracy for their complex
animation sequences to play as intended.
If anyone has had to calibrate the timing, or has any idea how, I would be
very interested in hearing how they did it. My plate is pretty full (I will be
crunching for quite a while it seems) so I was hoping that this was a well
known issue if you know what I mean ;-)
(Note added... still interested in calibration...)
#5
04/03/2005 (5:55 am)
Under Windows it has always been very accurate to 1000ms == 1s for me.
#6
04/03/2005 (9:17 am)
Are we all testing this on a clean copy of Torque 1.3?
#7
04/03/2005 (2:24 pm)
My test was a "almost clean" copy of 1.3. The change I have is for my own special object, which isn't anything real big. (AKA one extra include of a .cc and .h within the 1.3 build from the installer)
#8
I test at approx ~65 on a clean copy. Still far enough out to have me a little
concerned but no longer alarming. (Though I do need to fugure out what I
broke in my version ;-)
Sorry for being so full of doom and gloom without checking that out.
I am still very much interested in knowing if there is a good way to calibrate.
04/04/2005 (7:13 am)
HMMM. nope.I test at approx ~65 on a clean copy. Still far enough out to have me a little
concerned but no longer alarming. (Though I do need to fugure out what I
broke in my version ;-)
Sorry for being so full of doom and gloom without checking that out.
I am still very much interested in knowing if there is a good way to calibrate.
#9
Most of the time it works, but sometimes sentences are cut. I need accuracy here too!
Working also with 1.3, not clean.
04/04/2005 (7:42 am)
I'm in windows too, and I use the schedule thing to playback dialogues. I read a wav file's length, play it and then stop animations when the sound finishes. Most of the time it works, but sometimes sentences are cut. I need accuracy here too!
Working also with 1.3, not clean.
#10
04/04/2005 (9:27 am)
Could this be related to specific motherboards or versions of Windows? Also, you may get some inaccuracy if you have a low framerate (< 60FPS or so might be enough to see error creeping in...)
#11
Windows XP pro SP2.
ATI FireGL V3100
More info.
If I run this on just the client, then I get the discrepancy described.
The test is more or less accurate (about 1 sec. error per minute) when
a server is running.
Background Note: I am working on a single player game, with both 2D and 3D content.
I'm not always attached to the server. The server comes and goes with each 3D level
load... I do a fair amount of scripting in the client between missions, and have some
2D game activities that are purely in the client and don't start the server at all.
04/04/2005 (10:06 am)
Dell Precision 370, 3.2 GHz, (not sure what the exact motherboard is... I'll open it up later)Windows XP pro SP2.
ATI FireGL V3100
More info.
If I run this on just the client, then I get the discrepancy described.
The test is more or less accurate (about 1 sec. error per minute) when
a server is running.
Background Note: I am working on a single player game, with both 2D and 3D content.
I'm not always attached to the server. The server comes and goes with each 3D level
load... I do a fair amount of scripting in the client between missions, and have some
2D game activities that are purely in the client and don't start the server at all.
#12
Runnning a fresh and a highly modified TGE in the same benign TGE environment the above code produced these results(NOTE: Fresh and modified 1.3 returned the same results on mine)...
With no apps(besides TGE) and no unneeded services running..
Almost dead on 60 seconds(no more than 1/4 second difference)
With the CPU throttled to 50% load
65 seconds
With the CPU throttled to 100% load
68 seconds
If I had a celeron based machine around I would test on it but I suspect that if you loaded one of them to 50 or 100 percent that the times would be even greater. My guess is that your various testbed machines have various capabilities and that your longest times are coming from the weakest machines. You said you were using a lot of media and media is exactly what starts to eat up lots of CPU and memory. If your swap file ever came into play while running your test I'll bet the times would get crushed, lol.
The lessons to be learned here are that you never want a client to schedule his own events if they are playing in a multiplayer mode and you want to be generous with the timing of CPU intensive events. It's a pretty safe bet that a dedicated server will be able to provide good enough timing for almost every need.
04/07/2005 (11:54 pm)
I believe it's CPU related. I ran some tests on a Hyperthreaded machine(great for load testing) and found these specific things...Runnning a fresh and a highly modified TGE in the same benign TGE environment the above code produced these results(NOTE: Fresh and modified 1.3 returned the same results on mine)...
With no apps(besides TGE) and no unneeded services running..
Almost dead on 60 seconds(no more than 1/4 second difference)
With the CPU throttled to 50% load
65 seconds
With the CPU throttled to 100% load
68 seconds
If I had a celeron based machine around I would test on it but I suspect that if you loaded one of them to 50 or 100 percent that the times would be even greater. My guess is that your various testbed machines have various capabilities and that your longest times are coming from the weakest machines. You said you were using a lot of media and media is exactly what starts to eat up lots of CPU and memory. If your swap file ever came into play while running your test I'll bet the times would get crushed, lol.
The lessons to be learned here are that you never want a client to schedule his own events if they are playing in a multiplayer mode and you want to be generous with the timing of CPU intensive events. It's a pretty safe bet that a dedicated server will be able to provide good enough timing for almost every need.
#13
Ironically, the machine showing the biggest slowdown is the fastest machine. (Though it is a P4 with hyperthreading I believe... two cpu meters show in my task manager "performance" meter). I ran the test when the program was basically Idle.
For example, start up the demo (with the test function), pull down the console and run the test. This is where I ran the test. No server had been created yet. Under these conditions, I get the worst result.
If I load a level, then the timer becomes accurate. I haven't stepped into the code yet, but I suspect that the scheduler from the client is doing something different than either the server, or the "server connected" client. My schedule willing, I will step through this, but for the time being, I am wrestling with getting content and AI scripting to do what the designers expect ;-).
This project will never be multi-player, so I don't have that to deal with that (whew!). So I've moved a fair bit of stuff into the client, to reduce what needs to be thrown away and recreated between scenes.
As a possible work around, I suppose I could create a minimal dummy level to load (when I don't really need 3D) to insure I have the positive influence of the server on scheduling.
04/08/2005 (7:17 am)
This is good stuff Gonzo, but it doesn't really describe my situation. (Though we will need to start some compatibility testing before too awfully long, and will consider this.)Ironically, the machine showing the biggest slowdown is the fastest machine. (Though it is a P4 with hyperthreading I believe... two cpu meters show in my task manager "performance" meter). I ran the test when the program was basically Idle.
For example, start up the demo (with the test function), pull down the console and run the test. This is where I ran the test. No server had been created yet. Under these conditions, I get the worst result.
If I load a level, then the timer becomes accurate. I haven't stepped into the code yet, but I suspect that the scheduler from the client is doing something different than either the server, or the "server connected" client. My schedule willing, I will step through this, but for the time being, I am wrestling with getting content and AI scripting to do what the designers expect ;-).
This project will never be multi-player, so I don't have that to deal with that (whew!). So I've moved a fair bit of stuff into the client, to reduce what needs to be thrown away and recreated between scenes.
As a possible work around, I suppose I could create a minimal dummy level to load (when I don't really need 3D) to insure I have the positive influence of the server on scheduling.
Torque Owner John Vanderbeck
VanderGames