You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The "reducing variance" doc [1] recommends disabling hyper threading AND pinning CPU frequency scaling.
However, I tried doing this 6 different ways and discovered that pinning CPU frequency scaling appears to work incorrectly if hyper threads are disabled.
During my benchmark I monitored the CPU frequency of each enabled CPU and logged it each second. I could then analyze the log and determine that only the benchmarks with hyper threading enabled appeared to properly respect pinning CPU frequency scaling. Presumably this is some kind of kernel bug? Has anybody else come across this? And is there a work around?
So I ran the benchmark 6 times at ~ 300 seconds, and each time slightly changed the hyper thread / CPU frequency scaling config.
During the benchmark then each second I logged the MHz of each of the 12 or 24 enabled CPUs running the benchmark.
Run 1: hyper threads off and cpufreq governor set to "powersave":
Note: The p0 thru p100 is the percentile MHz from the 298 samples taken each second during the benchmarks.
Note: tmhz is the total of all MHz samples. So we would expect the totals to be the same if there is less variance, or?
Why set the governor to "ondemand" with the max frequency set to same as min?
Is that not similar to "powersave" governor? It seems not, from the results.
System
Ubuntu 22.04 LTS
To reproduce
This is not actually using the benchmark repo project, but rather just testing out the recommondations to reduce variance at [1].
Expected behavior
I would expect all the first 3 benchmarks to be the most accurate because hyper threads are disabled.
I would expected all benchmarks to have a similar total MHz for each CPU used in the benchmark.
However, in reality only benchmarks 4 and 5 appear to offer reduced variance RE CPU MHz.
It would be great if others could comment on there experiences with benchmarks and CPU frequency scaling.
Does anybody else actively monitor the CPU frequencies to sanity that the governor is doing its job?
Maybe the "reducing variance" doc [1] could be updated to warn not to take the governor for granted?
Screenshots
n/a
Additional context
The CPU in this case is an AMD Ryzen. Note: Boost mode was also disabled.
Describe the bug
The "reducing variance" doc [1] recommends disabling hyper threading AND pinning CPU frequency scaling.
However, I tried doing this 6 different ways and discovered that pinning CPU frequency scaling appears to work incorrectly if hyper threads are disabled.
During my benchmark I monitored the CPU frequency of each enabled CPU and logged it each second. I could then analyze the log and determine that only the benchmarks with hyper threading enabled appeared to properly respect pinning CPU frequency scaling. Presumably this is some kind of kernel bug? Has anybody else come across this? And is there a work around?
So I ran the benchmark 6 times at ~ 300 seconds, and each time slightly changed the hyper thread / CPU frequency scaling config.
During the benchmark then each second I logged the MHz of each of the 12 or 24 enabled CPUs running the benchmark.
Run 1: hyper threads off and cpufreq governor set to "powersave":
Run 2: hyper threads off and cpufreq governor set to default "ondemand" with max frequency set to same as min
Run 3: hyper threads off and cpufreq governor set to "performance"
Run 4: hyper threads on and cpufreq governor set to "powersave":
Run 5: hyper threads on and cpufreq governor set to default "ondemand" with max frequency set to same as min
Run 6: hyper threads on and cpufreq governor set to "performance"
Note: The p0 thru p100 is the percentile MHz from the 298 samples taken each second during the benchmarks.
Note:
tmhz
is the total of all MHz samples. So we would expect the totals to be the same if there is less variance, or?Why set the governor to "ondemand" with the max frequency set to same as min?
Is that not similar to "powersave" governor? It seems not, from the results.
System
Ubuntu 22.04 LTS
To reproduce
This is not actually using the benchmark repo project, but rather just testing out the recommondations to reduce variance at [1].
Expected behavior
I would expect all the first 3 benchmarks to be the most accurate because hyper threads are disabled.
I would expected all benchmarks to have a similar total MHz for each CPU used in the benchmark.
However, in reality only benchmarks 4 and 5 appear to offer reduced variance RE CPU MHz.
It would be great if others could comment on there experiences with benchmarks and CPU frequency scaling.
Does anybody else actively monitor the CPU frequencies to sanity that the governor is doing its job?
Maybe the "reducing variance" doc [1] could be updated to warn not to take the governor for granted?
Screenshots
n/a
Additional context
The CPU in this case is an AMD Ryzen. Note: Boost mode was also disabled.
[1] https://github.com/google/benchmark/blob/main/docs/reducing_variance.md
The text was updated successfully, but these errors were encountered: