Hello everyone, sorry for the late reply - this discussion slipped through my todo list. I’ve changed the internal flow for handling these requests to prevent that from happening again.
For your particular screenshotted time we do not have any logs Chaosius, which means your stations have not been connected to the SpringboardVR backend. Interestingly enough we do not have any logs for half of that week. This means we have no insight into what has happened on your station. Please note that SpringboardVR does not offer full offline support. We only offer the so-called Safety Mode, which exists to ensure smooth operation during sporadic internet connectivity (or in case of issues on our side).
This might be a symptom of an issue, which might be playing a role here.
18% utilization is on the higher end, higher than what we expect on a CPU like yours. This might be expected, depending on the boost clock achieved during that time. As we can see the CPU was not boosting to its full potential (just hitting 105% frequency), because it didn’t have to (it’s not hitting 100%). Whether or not your CPU can achieve its full potential depends on various factors, most of it relying on proper cooling.
Modern CPUs are dynamically changing their frequency all the time. The resource monitor doesn’t know about most of it, especially Intel’s Turbo Boost technology. This means the CPU usage you see is directly bound to the frequency at that moment in time. Due to your CPU not boosting to its full potential at that point there is nothing to worry about here - you are not resource-constrained, as you’re not hitting any hardware ceiling.
That being said if you’re getting 18% continuously that is too high - you should be sitting at around 10% at a maximum on that CPU while SteamVR is running. Even then, the additional 8% won’t change the performance characteristics of your machine there, as we can see it wasn’t peaking.
If you encounter performance issues please reach out to support@springboardvr.com and let us know the station name, approximate timestamp you were able to observe issues at and what state your station was in (idle, SteamVR on, in a game, with overlays visible or not). More importantly, we’d like to know whether you were able to observe that issue for more than 10 seconds. We can check what your station was doing during that time and troubleshoot with you from there on!
What follows below is intended to give you an overview of the technical details. There is no need to read or understand any/all of it. So if you’re interested, continue below!
As seen in your screenshot your station has hit 18% CPU utilization due to our background service. Your CPU in use is pretty much exactly hitting the recommended specification Oculus and HTC Vive have been requiring in 2016. While these hardware parties are keen on keeping the specs low, the reality is that VR content in 2019 (and now 2020) does not honor these. Especially in the LBE market we’ve seen customers having to rely on the higher end (even getting close to the ceiling of it), to ensure a hassle-free experience for their customers as well as their staff. A lot of content is made by small studios and as such performance optimization has not been equivalent compared to non-VR AAA titles on PC, so the above pretty much has been true from the beginning of this VR generation even.
The test machines we use for QA, which are either close to the recommended specification of the hardware vendors or close the average machine our customers use, show <7% CPU utilization of the background service. It can peak way higher on startup and settles down to the expected <7% usage after less than 10 seconds on average. The various Launcher environments we offer have way bigger resource needs - they are equivalent to other VR games. As such it is expected to regularly see a recommended spec machine to hit full CPU utilization.
Depending on the state of your station other factors play a role:
- When using the Idle Mode feature, set to Videos, we play the videos in a fullscreen window while your station is idle. Rendering the video will take up CPU resources on machines that do not offer hardware acceleration for this. The hardware support can be unexpected due to driver details. We’re working on using other technology for this feature to ensure a wider spectrum of hardware acceleration is available to it. This isn’t part of the
BackgroundService.exe process and will show up under CefSharp.BrowserSubprocess.exe instead.
- When your station is idle and there are pending changes to one-click titles we run those operations. This includes downloading, installing, updating, uninstalling and “healing” content. Any of these operations can use a lot of CPU resources - we want it to be finished quickly after all!
Of course, none of these states are possible while your station is actively running a game, as we only run the above when your station is idle. That being said some tasks can’t be canceled/paused immediately when exiting the idle state. After 10 seconds all tasks should be canceled/paused, though. Finally, there are these things that can additionally affect performance noticeably:
- Bringing up the SteamVR dashboard means we’re showing the SpringboardVR overlays. These overlays have to be rendered as part of our processes and then send over to SteamVR as a texture. While this is pretty fast, it does add to the resource usage, especially since we ensure we update the UI at the same refresh rate the VR headset is running at, to ensure smooth animations your users expect while in VR.
- If there’s incoming data to be processed by our backend we do that, even while a game is running. This will result in a short period of increased CPU usage.
If you’re checking the resource utilization of your station during any of these you can expect a brief period of peaking resource usage.
Last, and most importantly, our desktop client has to maintain a connection to SteamVR and communicate with it to react to your users closing the current app, showing the dashboard, etc. To ensure we react to the various events SteamVR has available for this we’re regularly polling for available events (SteamVR does not offer any push-based API). We run this polling loop at the refresh rate of the headset. In some cases, we’ve seen SteamVR bombard us with (uninteresting) events, due to their internal state machine getting into a broken state. A restart of SteamVR fixed this problem in those cases. This is obviously out of our control and as far as we know only affected a small number of stations on a few specific SteamVR versions a while ago.
