The following notes were taken during the Simulator User Group meeting of Tuesday, July 14th, 2020.
Please refer to the server deployment thread for news and updates:
- On Tuesday, July 21st, the majority of the grid was updated with server maintenance update 544832, designed to resolve issues with some internal service updates, chat range improvements and capability improvements.
- On Wednesday, July 22nd, the should be a single RC deployment comprising “a few internal changes (mostly logging)”. At the time of writing, the server deployment thread had yet to be updated with the release notes reference.
The Tools Update viewer, version 18.104.22.1684639, was promoted to de facto release status, Friday, July 17th. This viewer uses the new viewer build tool chain, but does not include any user-facing updates outside of bug fixes.
The remaining official viewer pipelines remain as follows:
- Release channel cohorts (please see my notes on manually installing RC viewer versions if you wish to install any release candidate(s) yourself):
- Project viewers:
- Custom Key Mappings project viewer, version 22.214.171.1244079, June 30th.
- Mesh uploader project viewer, version 126.96.36.1993141, June 11th.
- Copy / Paste viewer, version 188.8.131.523365, December 9th, 2019.
- Project Muscadine (Animesh follow-on) project viewer, version 184.108.40.2062999, November 22nd, 2019.
- Legacy Profiles viewer, version 220.127.116.110836, September 17th, 2019. Covers the re-integration of Viewer Profiles.
- 360 Snapshot project viewer, version 18.104.22.1689111, July 16th, 2019.
Further Regions in the Cloud
Following from the announcement concerning Ahern and Morris on Aditi, the beta grid, being in the cloud (see my previous Simulator User Group update), most / all of Blake Sea has been cloned to Aditi and is now running in the cloud, specifically for the purposes of region crossing tests with vehicles.
Again, just to emphasise, this is Aditi, the beta grid, only (at least one person has reported on region crossings on Agni (the main grid) in relation to this announcement). For more information, refer to my blog post Blake Sea in the cloud on ADITI.
What is Simulator “Sleep Time” and how are Scripts Processed?
The viewer provides a set of stats related to both itself and the simulator your user is on (CTRL-SHIFT-1). Most of the stats proved in this window are relatively self-explanatory, although some can cause confusion or can be misrepresented. One area of confusion – what is simulator “sleep time” – was raised in the forums recently, and Rider Linden took the time to explain it and a couple of other things in the stats panel. As his reply may help others, I’m including it in full here:
The short answer is that sleep time is the mean amount of time in ms per simulator frame that the simulator has spent idling over the last minute.
The long answer is that the simulators attempt to keep a constant number of processing frames (one cycle through the main loop) per second. This number is displayed in the statistics window as Sim FPS. This value is not the same as the Viewer’s FPS. When the Sim FPS starts to fall below 45 you will begin to see lag events like delayed movement and rubber banding, among other symptoms.
A single frame should take about 21ms. (21ms * 45) = ~1 second (less about 50ms overhead). If a single simulator frame takes less than that 21ms we need to add a few extra ms in order to maintain the constant rate. This extra time is reported as “Sleep Time” and tracks closely to “Spare Time”.
Every frame on the simulator is divided into a number of phases. The big ones are network message processing, advancing the state of the physics simulation, processing agents in the region and updating their interest lists, and executing scripts.
The amount of time allowed per frame to execute scripts is capped. The simulator will attempt to execute all the scripts in the region in that allotted time slice, if it can not make it all the way through the list it will stop and pick up where it left off on the next frame (this gives you the “Scripts Run %” statistic.) Since the time for script execution is capped you can see situations where the % of scripts executed per frame begins to fall even though there is idle time reported on the simulator.