Supermicro X9dri Turbo Boost problem and how to turn it properly ON Xeon e5-2680 v2

Notice: Page may contain affiliate links for which we may earn a small commission through services like Amazon Affiliates or Skimlinks.

bogi

New Member
Apr 4, 2020
19
0
1
I'm running Supermicro setup as workstation on x9dri-ln4f+ dual Xeon e5-2680v2 but no luck setting Turbo Boost properly.
System is used for 3D graphics and image file sequence 2D processing; frequency per core plays crucial role.
OS > Windows 10 Pro for Workstation update 20H2.
graphics Nvidia GTX 1080

When system starts Task Manager is opppened > under Performance I can see turbo is picking up to almost ~3.6GHz but after that any app. that is running can't reach more than ~2.8GHz default clock.

Gaming station performs much better under intel i7 gen4; turbo is picking up on that one to the maximum with any app.

What I found is the link on Supermicro support, it's related to X10 boards. It helped as a guide but not full spot on solution.
FAQ Entry | Online Support | Support - Super Micro Computer, Inc.

Please help with any suggestions.

Thank you!
 

MBastian

Active Member
Jul 17, 2016
205
59
28
Düsseldorf, Germany
Hard to say, since you see boosts up to 3.6GHz. Maybe thermal issues or an AVX workload?
That said turbo boost on Ivy Bridge CPUs seems to be rather sluggish. Even with one active thread pinned to one core I can't hit the 3.6 GHz limit on my E5-2690v2 CPUs (also in a x9dri-lnf4+ as a mainboard) the frequency hoveres around 3.3 to 3.45Ghz. Loading all cores I see the expected all-core turbo of 3.3GHz.
 
  • Like
Reactions: bogi

MBastian

Active Member
Jul 17, 2016
205
59
28
Düsseldorf, Germany
Only difference is that I've set "Power Technology" to "Disabled". I don''t think your setting makes a difference. If you reach a thermal or power limit ther might be someting in your Event Logs.
Did you check your Windows power management settings as @Neil Jefferies recommended? I am running Linux 99% of the time but I remember seeing a 3.3GHz all-core turbo while doing some Windows benchmarks out of curiosity.
 

MBastian

Active Member
Jul 17, 2016
205
59
28
Düsseldorf, Germany
I just ran `burnK6` on an otherwise idle system running archlinux and could not get more than a 3.3ish Ghz single core turbo. Strange thing is that most other cores did also ramp up to 3+ Ghz without doing anything. I fiddled a bit with `cpupower` and settings in /sys/ but it's quite late here. Anyone has some insight?
 

bogi

New Member
Apr 4, 2020
19
0
1
It looks like windows 10 power settings made slight and obvious improvement. Thank you @NeilJefferies

MaxTurbo that I can get under win10 performance settings is ~3.3GHz, better than 2.8
As mentioned earlier this is sluggish CPU and far from snappy i7 or higher clock E5 CPUs.

Thank you for your help!
 

Neil Jefferies

New Member
Jun 28, 2019
27
11
3
UK
neilstechdocs.blogspot.com
Linux tends to distribute its threads quite widely among CPU's and the default intel frequency governer spins them up to turbo speeds quite quickly. The general principle being that it uses less power getting the job done quickly and then idling (also remembering that the cpu frequency monitoring averages over a short period so under-reports both high and low frequency points). As far as the 3.3 GHz cap goes, it must be some motherboard setting - on my Z9PA-D8 Xeon 2680v2's spin up to 3.6 GHz quite happily on a single core. Some conky screenshots follow...

As idle as my (dual cpu) desktop gets (note, low temps so nothing happening despite apparently high frequencies)
Also note the left and right columns are the two hyperthreads on each core and the frequencies don't match because they are measured at different times.
1616162023269.png

One stress-ng thread - one core turbos up to 3.6ish and gets warm (also warms up adjacent cores)
1616162124391.png

20 stress-ng threads - all core turbo to 3.1GHz
Note the linux scheduler is smart enough to put one thread on each core though it may bounce between the two virtual threads. Which it does more on CPU1 than CPU2 for some reason!
1616162213314.png