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

sbc-bench on arm #4

Closed
sfx2000 opened this issue Oct 3, 2018 · 1 comment
Closed

sbc-bench on arm #4

sfx2000 opened this issue Oct 3, 2018 · 1 comment

Comments

@sfx2000
Copy link

sfx2000 commented Oct 3, 2018

Recommendation - don't change the CPU governors on sbc-bench - can report what's in use, but by changing it, it's hard to tell if exploring this item for a/b testing

echo performance >/sys/devices/system/cpu/cpu${i}/cpufreq/scaling_governor

@ThomasKaiser
Copy link
Owner

The readme of this project clearly explains the four different usage modes:

  • Generate a rough CPU performance assessment for a specific SBC in general (under ideal conditions)
  • Show whether an individual SBC is able to perform the same and if not hopefully answering the question 'why?'
  • Help software developers and hardware designers to improve 'thermal performance' when using the -t and/or -T switches (details/discussion, another example)
  • Provide basic CLI monitoring functionality through the -m switch

The first three usage modes require the cpufreq governor being set to performance to let cpufreq governor not alter performance behavior (and in 'thermal testing' mode allowing the cpufreq to decrease for other reasons than throttling making the whole reporting completely useless).

The last mode is for monitoring and doesn't alter the cpufreq governor.

What you're asking for is an interesting area of investigation: how does the chosen cpufreq settings (governor + other settings like min/max cpufreq or stuff like io_is_busy) negatively affects performance of boards. But unfortunately for this an entirely different set of tests is needed and I don't plan on adding this to this tool anytime soon or at all. Since getting an idea how/why cpufreq governors work requires to dig a lot more deeper than firing up some standard benchmarks and drawing the wrong conclusions.

Examples:

These issues can only be addressed by looking into details (the Active Benchmarking approach) and not by providing a tool that is meant to be operated in fire&forget mode.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants