Client side monitoring
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.
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.
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).
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.
The total number of prims in the region (not linksets).
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.
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.
Not currently used.
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.
Time taken to trigger or perform various miscellaneous frame tasks, such as terrain updates and processing of any listener methods to the frame event.
Processing of non-physics updates to scene entities (scene objects and presences).
Not currently used.
Not currently used. OpenSimulator performs script processing on separate threads with no work done in the main scene loop (frame) thread.
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.
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.
- http://community.secondlife.com/t5/English-Knowledge-Base/How-to-improve-Viewer-performance/ta-p/1316923 - more information on how to improve performance on the viewer-side.