precision timing question (and some wishful thinking ^^)

Hi there, I'm trying to understand the results i'm getting from this simple timing test, and hope that perhaps someone could explain what is happening..

The code below measures a series of consecutive intervals and displays the results.
(getTime() here is flawed in that it only gets the seconds from the timestamp)

The result tends to be mixture of really short and much longer intervals.

The first interval is always short.
Also the longer the loop runs for, the more often the longer intervals will tend to show up.

This gives me the impression that the script is somehow eventually choked by the server. Is this correct?

Wishful thinking bit: is there possibly a way to minimize this phenomenon? for example some way to let the timer catch its breath to prevent choking and give more consistent results?

cheers,
inso

// timer test
integer countMax = 16;
integer i;
list timestampList;
float timeStamp;
float timeStampPrevious;

float getTime()
{
	return (float) llGetSubString(llGetTimestamp(), 17, -2); // "ss.ff..f"
}

testIntervals()
{
	timestampList = ["timestamps"];
	timeStamp = getTime();

	for (i=0;i<countMax;++i)
	{
		timeStampPrevious = timeStamp;
		timeStamp = getTime();
		timestampList += (timeStamp - timeStampPrevious);
	}
	
	llSetText(llDumpList2String(timestampList,"\n"),<1.0,1.0,1.0>,1.0);
}

default
{
	state_entry()
	{
		llSetText("",<1.0,1.0,1.0>,1.0);
	}
	
	touch_start(integer total_number)
	{
		testIntervals();
	}
}
[END CODE]

All scripts running in a sim have to share script time. The more scripts run, the less time slices are available for each script and the higher "delays" on event processing may occur.

All that LSL timers grant you is that at *least* the specified amount of time passes before they are called.

So a llSleep(5.0) will grant you that at least five seconds pass before the script is unpaused.

And a llSetTimerEvent(1.5) will grant you that after a minimum of 1.5 seconds the timer event will be called.

Just a thought, do you get the same results if you don't keep storing and manipulating that longer and longer list, and just print out (llOwnerSay) the time intervals as they come?

as seifert pointed out, the larger the data being manipulated becomes, the longer that action wil take... the random quirck are the effect of time dialation, which can be throttled overall using a combination of the timer event and constantly monitoring dilation and setting the timer relative to it...

example:

timer(){
llSetTimerEvent( llGetRegionTimeDilation() );
//-- some stuff
}

this should help average out time dilation to NEAR 1 second, assuming all the code in 'some stuff' takes less than a second to run... if it doesn't then the timer becomes progressively queued

similarly handling an increasing list, the average processing time for each iteration gradually gets larger, so it will run progressively slower.

awesome thanks for the replies ^^

Finally I understand now, and was drawing the wrong conclusions.. you're both quite right about the increased data sizes..

I think I'll quietly withdraw now from my attempt at "precision" timing in SL and stick to sound ques after all

cheers,
inso

the above method will keep pretty accurate timing on average as long as you account for the extra proccessing time that a larger data manipulation will need. it is however very intensive use of resources, and increases usage the more time dilation drops.... I wouldn't use it for anything not critical to timing, and you definitely want to put some cutoffs in there so that you aren't making a bad lag situation much worse.

Yeah true regarding resources.. The reason for my questions are that I'm playing around with a clock source for triggering musical notes in a controllable sequence and have been using roughly the following timing method.. it uses a lot of resources i'm sure but tried to minimize resource use by jumping nearer the end of the required cycle.
This one just triggers once a second synced to the timestamp but then can run multiple instants triggering at offsets of this to increase resolution for example.

integer pollTime;

timer()
	{
		llSetTimerEvent(0.0);
pollTime = TRUE;
		do
		{
			timeStamp = getTime();
			if (timeStamp >= nextTimeTarget) pollTime = FALSE;
		}
		while (pollTime);
		nextTimeTarget = (float)llCeil(getTime());
		llSetTimerEvent(llGetRegionTimeDilation()/1.5);

		triggerSoundTick();
	}

I'm assuming getTime should be llGetTime ? be careful there as that number is affected by sim time dialtion... so controlling excution by it will also be affected by time dialtion.

if you need to test for accurate RL time, you'll want to test against llGetWallclock, llGetGMTclock, llGetUnixTime, or llGetTimestamp.

for extended info like days months etc, use timestamp (you'll prpbably want to parse it), for continuous timers use unix time, for auto adjusted DST use wallclock (will adjust to USA DST) and for a clock w/o DST use the gmt function

most handed clocks use GMT or Wallclock, to get hourly chicmes you can modulus the result to 3600 and use /3600 to get the actual hour... for 12 hr clocks you might want to modulus the input first with 43200 (12 hours in seconds) so you don't chime 13+... calling the timer ever 5 seconds you can prevent recalling the chime by checking if the result after modulus is < 5... that also prevents most lag from affecting your chime sequences.

sorry getTime was referring to a function that grabs a numerical llGetTimeStamp

get Unix time might be faster to parse for you then.

k thanks i'll give that a go..