Client side monitoring
From OpenSimulator
(→Viewer statistics) |
(→Active Objects) |
||
(10 intermediate revisions by one user not shown) | |||
Line 9: | Line 9: | ||
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. | 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 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 |
+ | |||
+ | == Basic == | ||
+ | ===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). | ||
+ | |||
+ | ===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 = | ||
Line 18: | Line 67: | ||
See http://wiki.secondlife.com/wiki/Texture_Console for more details. | See http://wiki.secondlife.com/wiki/Texture_Console for more details. | ||
+ | |||
+ | = References = | ||
+ | * 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. |
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.
[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
- 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.