Does compute pressure reflect OS-level speed limit changes due to throttling?

[brycepj]

I work on video conferencing software that is embedded within a much larger, CPU-intensive application. We frequently deal with performance and quality issues that can be traced back to speed-limit changes triggered by thermal throttling or power management.

Since the PressureObserver API currently only supports the 'cpu' source, my question is whether compute pressure is calculated in a way that would reflect these throttling effects. In other words, if the operating system adjusts speed limits due to thermal or power constraints, would these changes be reflected in the compute pressure?

While I'm excited for the prospect of using other pressure sources in the future, I'm interested to understand if the compute pressure metric effectively serves as a catch-all, inclusive of the impacts from OS-level changes. I would appreciate any insights or clarifications.

[anssiko]

@brycepj, thanks for sharing your use case and questions. I'm hearing that you'd prefer a catch-all source that considers global thermal and power constraints? Would such a catch-all source be adequate or would your use cases in addition require processing unit-level insight?

We evolve this API based real-world use cases such as yours. Feel free to watch this repo and take part in related design discussions as they emerge. Thank you for your contributions.

I'll label this as "v2" to give it better visibility in our issue triage.

[brycepj]

Thanks for your thoughtful response 🙇

Yes, I do think a catch-all source would be valuable. The primary uses we have at Slack for this feature are:

• detecting when a device is not capable of a fully-featured experience, so that we can alert the user and/or gracefully degrade. If thermal and/or power-related throttling is happening, we almost always observe noticeable differences in a/v quality, as well as Slack's responsiveness. In this case, distinguishing between compute pressure and thermal/power-related pressure is not as important as detecting the system's overall capabilities.
• diagnosing the source of problems based on user reports or support requests(after the fact). If we're able to identify that a user's device is the source of the problem based on a catch-all value (rather an a performance problem with Slack or Huddles), we're not going to spend as much time investigating, but rather provide helpful troubleshooting tips or information. So a catch-all value that flags that the system's capabilities were limited would help us make that decision quickly. In this case, distinguishing between thermal/power related throttling and CPU pressure would be helpful in providing the user more targeted help. But a catch-all source would still be an improvement if in fact compute pressure does not capture thermal or power-related throttling.

[kenchris]

Since the PressureObserver API currently only supports the 'cpu' source, my question is whether compute pressure is calculated in a way that would reflect these throttling effects.

We recently added "thermals" as a source as well that it intended to reflect whether the system is being throttled or not. We did need to find the best way to implement this on different systems, as it is not always straight forward.

[brycepj]

@anssiko @kenchris Thanks for the responses. We're very excited about developments here and eager to help however we can. For what it's worth, we're already experimenting with these APIs internally and will be expanding to Slack's customers in the coming weeks. If there's any information or data I can provide about our experience that would help you all, please do let me know.

[anssiko]

@brycepj, thank you. The intent of the Origin Trial is exactly to collect real-world feedback from users of the API.

Please keep sharing your suggestions, feedback and questions in this issue, or open new issues as appropriate. I've scheduled time to discuss your feedback with the entire Working Group at our next f2f meeting that takes place mid-September.

[kenchris]

@brycepj We are very happy that you are playing around with the API and giving up this feedback. We would like to know if we could mention this publicly, say on presentation slides, possible together with your company logo?

[arskama]

@brycepj

The Compute Pressure API was released on Chromium M125.

Did you try it with Slack? Do you have any experience to share with us?

[brycepj]

Yes, we do observe compute pressure during Huddles with this API and have since M125. We don't currently use compute pressure levels to dynamically adapt quality, but do use it in internal reporting around performance/quality and as a diagnostic for reports about poor quality or performance. In general, I have found it quite useful/reliable for these things.

We haven't yet used the 'thermals' source, mainly because we already use a comparable event emitted by Electron to detect thermal states. But I think it would be preferable to be using a Chromium API for this, so I'll definitely experiment with it and see how that goes.

[arskama]

@brycepj Great to hear that! Thanks.

"thermal" source is not yet supported, since we haven't found yet a good generic way to support it accross platforms and OSes.

At the moment we are working on the feasibility of #8 and we would like to hear if you could see any benefit for your product.

[arskama]

@brycepj we are working on this feature: #298
Can you provide any comments, and if you see any benefit for your product?