Client side monitoring

From OpenSimulator

(Difference between revisions)
Jump to: navigation, search
(Ping Sim)
(Active Objects)
 
(6 intermediate revisions by one user not shown)
Line 13: Line 13:
 
See also http://community.secondlife.com/t5/English-Knowledge-Base/How-to-improve-Viewer-performance/ta-p/1316923
 
See also http://community.secondlife.com/t5/English-Knowledge-Base/How-to-improve-Viewer-performance/ta-p/1316923
  
==Ping Sim==
+
== Basic ==
 +
===Ping Sim===
 
A typical viewer will send a ping UDP packet (StartPingCheck) to the root region every 5 seconds.   
 
A typical viewer will send a ping UDP packet (StartPingCheck) to the root region every 5 seconds.   
  
Line 20: Line 21:
 
If the simulator is on the same computer as the viewer, then you would expect to see a ping time of approximately 10-25 ms.  If the simulator is remote, then ping times will be a lot longer as the packet traverses the network.
 
If the simulator is on the same computer as the viewer, then you would expect to see a ping time of approximately 10-25 ms.  If the simulator is remote, then ping times will be a lot longer as the packet traverses the network.
  
If ping time varies significantly (e.g. by 100s of ms) or is consistently higher than one would expect then this may indicate an extremely over-loaded simulator or network problems/high latency between the viewer and the simulator.
+
If ping time varies significantly (e.g. by 100s of ms) or is consistently higher than one would expect then this may indicate an extremely over-loaded simulator or network problems/high latency between the viewer and the simulator.  However, ping can sometimes also leap up if the viewer is overloaded (and hence taking more time than usual to process incoming data).
 +
 
 +
===Packet Loss===
 +
This is the percentage of all UDP packets sent from the viewer to the simulator that were not acknowledged by the simulator, indicating that they were lost.  Any packet loss is not good - a packet loss of over 10% indicates serious problems.  A high packet loss may be due to a bad network connection between your viewer and the server, problems with the viewer or overloading of the server, amongst other things.
 +
 
 +
==Simulator==
 +
===Objects===
 +
The total number of prims in the region (not linksets).
 +
 
 +
===Active Objects===
 +
In OpenSimulator, this is currently the total number of prims that are subject to physics (i.e. two prims in a link set count as two active objects).
 +
 
 +
On the Linden Lab grid, by contrast, this appears to be the number of linksets that are actively being physics simulated (i.e. an object that is flagged as physics but is completely at rest will not be counted).  At least as of 2013-11-13, the Linden wiki page links that state this statistic records the number of objects containing scripts appears to be wrong.
 +
 
 +
==Time (ms)==
 +
This is a breakdown of where the time is spent in each frame of the simulation. 
 +
 
 +
===Total Frame Time===
 +
In OpenSimulator each frame should complete in approximately 18.18 ms (55 frames per second).  If total frame time is greater than this than simulator performance will be degraded.
 +
 
 +
===Net Time===
 +
Not currently used.
 +
 
 +
===Physics Time===
 +
The amount of time taken to complete physics processing within the frame.  Is this causes total frame time to be greater than 18.18 ms then the number of physical objects or the complexity of those objects on the region needs to be reduced.
 +
 
 +
===Simulation Time===
 +
Time taken to trigger or perform various miscellaneous frame tasks, such as terrain updates and processing of any listener methods to the frame event.
 +
 
 +
===Agent Time===
 +
Processing of non-physics updates to scene entities (scene objects and presences).
 +
 
 +
===Images Time===
 +
Not currently used.
 +
 
 +
===Script Time===
 +
Not currently used.  OpenSimulator performs script processing on separate threads with no work done in the main scene loop (frame) thread.
 +
 
 +
===Spare Time===
 +
This is the amount of time left within the standard frame time after all necessary work has been done.  OpenSimulator sleeps the thread for this period.
  
 
= Texture Console =
 
= Texture Console =

Latest revision as of 14:48, 13 November 2013

Contents

[edit] Introduction

This page refers to monitoring facilities that are typically present on a viewer. These are not directly connected with OpenSimulator.

Please add more detail as necessary.

[edit] Viewer statistics

The short cut to display this window is CTRL + SHIFT + 1. This shows measures such as viewer frames per second (FPS), Total Frame Time, etc.

Information about a few of these measures is broken out below.

See also http://community.secondlife.com/t5/English-Knowledge-Base/How-to-improve-Viewer-performance/ta-p/1316923

[edit] Basic

[edit] Ping Sim

A typical viewer will send a ping UDP packet (StartPingCheck) to the root region every 5 seconds.

The simulator will respond immediately with a CompletePingCheckPacket without going through the main packet queueing mechanism. The viewer measures the round-trip time and displays this as the Ping Sim statistic.

If the simulator is on the same computer as the viewer, then you would expect to see a ping time of approximately 10-25 ms. If the simulator is remote, then ping times will be a lot longer as the packet traverses the network.

If ping time varies significantly (e.g. by 100s of ms) or is consistently higher than one would expect then this may indicate an extremely over-loaded simulator or network problems/high latency between the viewer and the simulator. However, ping can sometimes also leap up if the viewer is overloaded (and hence taking more time than usual to process incoming data).

[edit] Packet Loss

This is the percentage of all UDP packets sent from the viewer to the simulator that were not acknowledged by the simulator, indicating that they were lost. Any packet loss is not good - a packet loss of over 10% indicates serious problems. A high packet loss may be due to a bad network connection between your viewer and the server, problems with the viewer or overloading of the server, amongst other things.

[edit] Simulator

[edit] Objects

The total number of prims in the region (not linksets).

[edit] Active Objects

In OpenSimulator, this is currently the total number of prims that are subject to physics (i.e. two prims in a link set count as two active objects).

On the Linden Lab grid, by contrast, this appears to be the number of linksets that are actively being physics simulated (i.e. an object that is flagged as physics but is completely at rest will not be counted). At least as of 2013-11-13, the Linden wiki page links that state this statistic records the number of objects containing scripts appears to be wrong.

[edit] Time (ms)

This is a breakdown of where the time is spent in each frame of the simulation.

[edit] Total Frame Time

In OpenSimulator each frame should complete in approximately 18.18 ms (55 frames per second). If total frame time is greater than this than simulator performance will be degraded.

[edit] Net Time

Not currently used.

[edit] Physics Time

The amount of time taken to complete physics processing within the frame. Is this causes total frame time to be greater than 18.18 ms then the number of physical objects or the complexity of those objects on the region needs to be reduced.

[edit] Simulation Time

Time taken to trigger or perform various miscellaneous frame tasks, such as terrain updates and processing of any listener methods to the frame event.

[edit] Agent Time

Processing of non-physics updates to scene entities (scene objects and presences).

[edit] Images Time

Not currently used.

[edit] Script Time

Not currently used. OpenSimulator performs script processing on separate threads with no work done in the main scene loop (frame) thread.

[edit] Spare Time

This is the amount of time left within the standard frame time after all necessary work has been done. OpenSimulator sleeps the thread for this period.

[edit] Texture Console

The short cut to display this is CTRL + SHIFT + 3. This will overlay a display on the viewer which details the textures being downloaded and thedownload progress. The number of textures present on the region is the number after the "Textures:" text on the third line of the display. The higher this is, the more graphics memory is required from the viewer and lower performance will be.

See http://wiki.secondlife.com/wiki/Texture_Console for more details.

[edit] References

Personal tools
General
About This Wiki