Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Opt-in for providing basic Hardware Information #28055

Open
tannergooding opened this issue Sep 20, 2022 · 1 comment
Open

Opt-in for providing basic Hardware Information #28055

tannergooding opened this issue Sep 20, 2022 · 1 comment
Milestone

Comments

@tannergooding
Copy link
Member

tannergooding commented Sep 20, 2022

As per the discussion that started on https://twitter.com/xoofx/status/1572286062315311104?s=20&t=vlg_eVRuF3LDg3C-4_W-og

It might be beneficial for there to be an opt-in for users to provide basic hardware information as part of telemetry collection. It may likewise be beneficial for .NET to do semi-annual surveys in which users can self-report this information to help gather additional datapoints.

The Steam Hardware Survey publishes monthly and contains a wealth of information. However, that information is really centered around the gaming industry and doesn't necessarily correlate to .NET developers.

Almost all of the metrics that Steam collects could be beneficial to help drive decisions both for .NET itself and for the community developing on .NET. Thus I would suggest that the data be provided as available alongside the existing telemetry: https://dotnet.microsoft.com/en-us/platform/telemetry. It might be further beneficial for the hardware data to be represented in a more friendly user manner like it is for Steam.

For the purposes of the runtime, the most interesting information is likely:

  • CPU Count (both Physical and Logical)
  • CPU Features (namely which optional ISAs are supported)
  • CPU Cache Sizes (I don't believe Steam collects this one)
  • CPU Speed and RAM amount may also be good information

These can be used to better tune where optimizations are focused and help further fine-tune specific scenarios like thread-pool sizes and concurrency primitives.

@jkotas
Copy link
Member

jkotas commented Sep 21, 2022

This would help runtime if this information is collected on all machines where .NET runtime runs, including production machines. If you collect this information only in places where .NET SDK runs, I do not think it is very useful for the general runtime decision making.

@marcpopMSFT marcpopMSFT added this to the Backlog milestone Sep 28, 2022
@marcpopMSFT marcpopMSFT removed the untriaged Request triage from a team member label Sep 28, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants