Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0003862opensim[REGION] Scripting Enginepublic2009-07-03 09:152021-11-18 11:08
Reporterjfhopkin 
Assigned To 
PrioritynormalSeveritymajorReproducibilityalways
StatusacknowledgedResolutionopen 
PlatformOperating SystemOperating System Version
Product Version 
Target VersionFixed in Version 
Summary0003862: Script timer events badly inaccurate over a period
DescriptionThe timer isn't dependable enough over a given period. This makes some functions in SL unusable in OpenSim. For example, swing scripts which rely on coordinating llTargetOmega() rotation with timer() events, work fine in SL but are unusable in OpenSim. Even a clock which ticks every second sounds noticeably arrhythmic in OpenSim but fine in SL.

Note that some inaccuracy in the execution individual timer events is perfectly understandable; however, over time these inaccuracies should start to average close to zero. Instead, they compound.

See Additional Information for a comparative test between OS and SL.

P4/3.6GHz/2GB
Ubuntu Jaunty
Mono 2.2
XEngine
Additional InformationDrop this in a prim:

default
{
    state_entry()
    {
        llSetTimerEvent(10.0) ;
    }
    timer()
    {
        llSay(0, (string)llGetTime()) ;
    }
}

Result in OpenSim:

[07:53] Primitive: 10.165108
[07:53] Primitive: 20.195535
[07:53] Primitive: 30.234698
[07:53] Primitive: 40.281795
[07:53] Primitive: 50.375598
[07:54] Primitive: 60.420302
[07:54] Primitive: 70.451000
[07:54] Primitive: 80.507164
[07:54] Primitive: 90.571056
[07:54] Primitive: 100.603898
[07:54] Primitive: 110.702383
[07:55] Primitive: 120.745550
[07:55] Primitive: 130.787046
[07:55] Primitive: 140.816682
[07:55] Primitive: 150.864184
[07:55] Primitive: 160.946772
[07:55] Primitive: 170.982877
[07:56] Primitive: 181.015696

Showing a net gain of nearly a second in 3 minutes.

By contrast, in SL:

[9:03] Object: 10.224720
[9:03] Object: 20.130380
[9:04] Object: 30.152020
[9:04] Object: 40.153270
[9:04] Object: 50.169860
[9:04] Object: 60.173560
[9:04] Object: 70.191370
[9:04] Object: 80.217800
[9:05] Object: 90.218410
[9:05] Object: 100.221700
[9:05] Object: 110.236800
[9:05] Object: 120.254100
[9:05] Object: 130.268400
[9:05] Object: 140.267700
[9:06] Object: 150.295500
[9:06] Object: 160.273300
[9:06] Object: 170.301800
[9:06] Object: 180.298100

Showing barely a significant difference.
TagsNo tags attached.
Git Revision or version number
Run Mode Grid (Multiple Regions per Sim)
Physics EngineODE
Script Engine
EnvironmentMono / Linux32
Mono Version2.2
Viewer
Attached Files

- Relationships

-  Notes
(0012320)
Godfrey (reporter)
2009-07-03 19:30

How many threads are you using for script execution, what's your minimum timer interval set to, and how many other scripts are running in the regions?

In my OpenSim.ini, I've got NumberOfScriptThreads=10 and MinTimerInterval=0.04, and I get these results on a region with 525 active scripts:

[18:16] Primitive: 10.199426
[18:16] Primitive: 20.207934
[18:17] Primitive: 30.218435
[18:17] Primitive: 40.306709
[18:17] Primitive: 50.316242
[18:17] Primitive: 60.324550
[18:17] Primitive: 70.333489
[18:17] Primitive: 80.342190
[18:18] Primitive: 90.350817
[18:18] Primitive: 100.444205
[18:18] Primitive: 110.458541
[18:18] Primitive: 120.472739
[18:18] Primitive: 130.485798
[18:18] Primitive: 140.494710
[18:19] Primitive: 150.503225
[18:19] Primitive: 160.592832
[18:19] Primitive: 170.607614
[18:19] Primitive: 180.621921

And on a region with 25 active scripts, I get:

[18:22] Primitive: 10.174351
[18:22] Primitive: 20.204337
[18:22] Primitive: 30.211862
[18:22] Primitive: 40.219029
[18:23] Primitive: 50.249916
[18:23] Primitive: 60.256769
[18:23] Primitive: 70.287368
[18:23] Primitive: 80.293985
[18:23] Primitive: 90.300427
[18:23] Primitive: 100.331021
[18:24] Primitive: 110.337854
[18:24] Primitive: 120.344467
[18:24] Primitive: 130.374882
[18:24] Primitive: 140.381355
[18:24] Primitive: 150.387708
[18:24] Primitive: 160.417977
[18:25] Primitive: 170.424480
[18:25] Primitive: 180.436992

Obviously, still not terribly precise - but quite a bit closer to SL's timing. Those are running on two different machines, by the way, since script threads are shared amongst all regions running in the same instance. I don't have a realtime kernel installed on either of those machines, if it matters.

Also, just as an aside - instead of using a timer for clock ticks, it's much more efficient to use a soundfile that's exactly a second long (or multiples thereof) and play it looped.
(0012322)
jfhopkin (reporter)
2009-07-04 10:21

On the region I'm using for testing, there are 27 scripts according to the "top scripts" panel. The total by the same measure is about 58 scripts; I'm pretty certain this is an underestimate. Is there a better measure?

Anyway, I added entries for:

NumberOfScriptThreads = 10
MinTimerInterval = 0.04

into the XEngine section of OpenSim.ini (an assumption - only the first exists i the example, and that's in the DotNetEngine section), rebooted the sim, and got:

[08:43] Primitive: 10.264934
[08:43] Primitive: 20.296376
[08:43] Primitive: 30.362051
[08:43] Primitive: 40.391368
[08:43] Primitive: 50.419698
[08:44] Primitive: 60.423383
[08:44] Primitive: 70.457891
[08:44] Primitive: 80.485201
[08:44] Primitive: 90.533604
[08:44] Primitive: 100.562185
[08:44] Primitive: 110.602805
[08:45] Primitive: 120.644673
[08:45] Primitive: 130.691793
[08:45] Primitive: 140.736173
[08:45] Primitive: 150.763696
[08:45] Primitive: 160.816368
[08:45] Primitive: 170.876923
[08:46] Primitive: 180.925256

Still creeping forward, but a little less so than before, which I guess could be a side-effect of restarting the sim, or due to the additional parameters.
(0012323)
melanie (administrator)
2009-07-04 11:17

XEngine doesn't use NumberOfScriptThreads and the MinTimerInterval has no bearing on this. Script timers are by definition not accurate and not dependable either short or long term. Please do not depend on them.
I realize this is a legitimate concern and therefore I'm not closing the Mantis, but unless and untl we have microthreading, it will not be possible to make them as accurate as you would wish. I would suggest using the *UnixTimestamp functionality to get a wallclock timebase for longer timers.
(0012325)
jfhopkin (reporter)
2009-07-05 02:56

Understood, Melanie. Thanks for your help.
(0038191)
tampa (reporter)
2021-10-31 07:25

On a rather full simulator running 3000 scripts on YEngine:

[07:13] Object: 10.099000
[07:13] Object: 20.100000
[07:14] Object: 30.142000
[07:14] Object: 40.174000
[07:14] Object: 50.216000
[07:14] Object: 60.311001
[07:14] Object: 70.363998
[07:14] Object: 80.463997
[07:15] Object: 90.484001
[07:15] Object: 100.593002
[07:15] Object: 110.600998
[07:15] Object: 120.675003
[07:15] Object: 130.764999
[07:15] Object: 140.826996
[07:16] Object: 150.921997
[07:16] Object: 161.014008
[07:16] Object: 171.095001
[07:16] Object: 181.195007
[07:16] Object: 191.223007
[07:16] Object: 201.304993
[07:17] Object: 211.341995
[07:17] Object: 221.354996
[07:17] Object: 231.367996
[07:17] Object: 241.417999
[07:17] Object: 251.436005
[07:17] Object: 261.519989
[07:18] Object: 271.540009

I'd say could give YEngine a bit of tweak perhaps, but it holds up pretty well given the load. I tested on XEngine on an empty simulator and that held up a bit better than the examples posted thus far.

Acknowledge the issue, but whether something can be done other than tweaking here and there is debatable. A good option is to reset timers when they reach certain timeframes using a simple iterating int and some if. Though for accurate timing you may want to rely on actual system clocks as Melanie said.
(0038192)
tampa (reporter)
2021-10-31 07:42

I think perhaps part of the issue is the way numbers work in general. Remember, 10 != 10.0f

llSetTimerEvent(9.977777777f); produced:

[07:31] Object: 10.049000
[07:31] Object: 20.038000
[07:32] Object: 30.100000
[07:32] Object: 40.143002
[07:32] Object: 50.143002
[07:32] Object: 60.178001
[07:32] Object: 70.204002
[07:32] Object: 80.249001
[07:33] Object: 90.237999
[07:33] Object: 100.283997
[07:33] Object: 110.341003
[07:33] Object: 120.316002
[07:33] Object: 130.427002
[07:33] Object: 140.440994
[07:34] Object: 150.425003
[07:34] Object: 160.477997
[07:34] Object: 170.488007
[07:34] Object: 180.462006
[07:34] Object: 190.460007
[07:34] Object: 200.466003
[07:35] Object: 210.496002
[07:35] Object: 220.552994
[07:35] Object: 230.584000
[07:35] Object: 240.647003
[07:35] Object: 250.623993
[07:35] Object: 260.686005
[07:36] Object: 270.665009
[07:36] Object: 280.699005
[07:36] Object: 290.686005

I would say you could probably create a self-adjusting timer based on the average deviation over a set period of time. I think internally we might be able to cast the numbers or apply some fixing to proper values to reduce some deviation, but I have not looked at the code specifically.

What's interesting is the pattern of adding deviation and then going back down again repeating with some regularity on that region, potentially a hint at what threading does in the background.

Adjusting the timer value and restarting it once deviation gets too large seems to be best and I would imagine this is either tied directly to some system clock or done internally over at SL. Self-control code for timers I don't think is the right approach though as the overhead that would add to the timers might just compound the issue and create a lot more resource(cpu) usage for something that is meant to be as light as possible.
(0038194)
UbitUmarov (administrator)
2021-10-31 09:34
edited on: 2021-10-31 09:35

Yes lsl timer may cumulative drift according to region load
The particular script engine has little impact on that

(0038239)
BillBlight (developer)
2021-11-18 11:08

This also may vari by operating system and/or CPU type.

You can mitigate this a little bit by basing it off of llGetWallclock +/- ...

I started using llGetWallclock +/- over long running timers quite a while back.

- Issue History
Date Modified Username Field Change
2009-07-03 09:15 jfhopkin New Issue
2009-07-03 09:15 jfhopkin SVN Revision => 9943
2009-07-03 09:15 jfhopkin Run Mode => Grid (Multiple Regions per Sim)
2009-07-03 09:15 jfhopkin Physics Engine => ODE
2009-07-03 09:15 jfhopkin Environment => Mono / Linux32
2009-07-03 09:15 jfhopkin Mono Version => 2.2
2009-07-03 19:30 Godfrey Note Added: 0012320
2009-07-04 10:21 jfhopkin Note Added: 0012322
2009-07-04 11:17 melanie Note Added: 0012323
2009-07-05 02:56 jfhopkin Note Added: 0012325
2009-08-08 06:41 Fly-Man- Status new => feedback
2021-10-31 07:25 tampa Note Added: 0038191
2021-10-31 07:25 tampa Status feedback => acknowledged
2021-10-31 07:42 tampa Note Added: 0038192
2021-10-31 09:34 UbitUmarov Note Added: 0038194
2021-10-31 09:35 UbitUmarov Note Edited: 0038194 View Revisions
2021-11-18 11:08 BillBlight Note Added: 0038239


Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker