[Opensim-users] Default .ini settings question

[Justin Clark-Casey]

On 09/08/10 22:47, Mark Dubin wrote:
> There are numerous default settings in OpenSim.ini that are possibly
> related to client performance lag. I cannot (at least readily) find
> explanations of how these defaults affect performance if they are
> increased or decreased or changed. I would like to know, thus this posting.
>
> Here are normally used ones I think are relevant to my question, and
> their defaults. If you know the impact of changing any of them, please
> post to this list, or off-line to me by e-mail. I will collate the
> answers and add them to the Wiki in an appropriate manner, perhaps as a
> separate linked page.
>
> I apologize in advance to those who think the answers are self-evident
> :D Thanks, Mark

I know a few of these, though unfortunately not all off the top of my head.

>
> ----------
> ; Max threads to allocate on the FireAndForget thread pool when running
> with the SmartThreadPool option above
> MaxPoolThreads = 15
>
> ; Objects will be considered for persistance in the next sweep when they
> have not changed for this number of seconds
> MinimumTimeBeforePersistenceConsidered = 60

Amount of time before a new or changed scene object can be persisted to the database.  On this setting, if one moves a 
prim then the details will not be updated until at least 60 seconds have passed.

>
> ; Objects will always be considered for persistance in the next sweep if
> the first change occurred this number of seconds ago
> MaximumTimeBeforePersistenceConsidered = 600

Amount of time after which a scene object will always be persisted.  For instance, suppose that an object has a script 
that changes it every 45 seconds.  If we only had the MinimumTimeBeforePersistenceConsidered setting above, then the 
object would never be updated in the database since it never reaches 60 seconds without changing.

However, with the setting of 600 here, that scene object will always be made to persist after 600 seconds have passed.

>
> ; Maximum number of llListen events we allow per script. Set this to 0
> to have no limit imposed.
> max_listens_per_script = 64
>
> [XEngine]
> ; How many threads to start at maximum load
> MaxThreads = 100
>
> [XEngine]
> ; Time a thread must be idle (in seconds) before it dies
> IdleTimeout = 60
>
> [XEngine]
> ; Thread priority ("Lowest", "BelowNormal", "Normal", "AboveNormal",
> "Highest")
> Priority = "BelowNormal"

This refers to thread priority in the VM.  Afaik, this is not yet implemented in Mono (would love to know if I'm wrong). 
  Higher priorities would theoretically give script threads some precendence over other OpenSim thrads.

>
> [XEngine]
> ; Maximum number of events to queue for a script (excluding timers)
> MaxScriptEventQueue = 300

This refers to LSL events.  The higher this number, the more that can stack up waiting to be dealt with.

>
> [XEngine]
> ; Stack size per thread created
> ThreadStackSize = 262144
>
> [XEngine]
> ; Interval (s) between background save of script states
> SaveInterval = 120

Script state is all the variables in an LSL script.  I presume that on a setting of 120 this will be persisted every 2 
minutes.  If your sim crashes the script would revert to the previously persisted state.

>
> [XEngine]
> ; Interval (s) between maintenance runs (0 = disable)
> MaintenanceInterval = 10
>
> [XEngine]
> ; Time a script can spend in an event handler before it is interrupted
> EventLimit = 30
>
> [XEngine]
> ; If a script overruns it's event limit, kill the script?
> KillTimedOutScripts = false
>
> [XEngine]
> ; Sets the multiplier for the scripting delays
> ScriptDelayFactor = 1.0

This refers to the delays built into each script command to stop a region being overloaded.  If 1.0, then the normal 
Linden Lab delays are used (see LSL wiki and such for details).  If 0.0, then there are no delays.

>
> [InterestManagement]
> ; This section controls how state updates are prioritized for each client
> ; Valid values are Time, Distance, SimpleAngularDistance, and FrontBack
> UpdatePrioritizationScheme = FrontBack
> ReprioritizationEnabled = true
> ReprioritizationInterval = 2000.0
> RootReprioritizationDistance = 10.0
> ChildReprioritizationDistance = 20.0

This affects how prim information is sent to the viewer.  I believe Time prioritizes them by when the server requests 
the update is sent.  Distance by how close they are to the viewer.  SimpleAngularDistance is currently identical to 
Distance.  FrontBack increases priorities for objects in front and decreases it for those behind.

-- 
Justin Clark-Casey (justincc)
http://justincc.org
http://twitter.com/justincc