Question AMD Ryzen 2700X won't hit 100% all cores

[below20hz]

I just built a new machine for myself this past month, mostly for encoding my blu-ray library. When it was first completed (stock, no OC on Windows 10 Pro, MSI MPG X570 Gaming Plus Motherboard), when I would use Handbrake or BD3D2MK3D, all cores would hit 100% at 3700mHz, which is exactly what I expected and wanted. But since then something has changed (power settings? update? BIOS?) and now when I run an encode, the cores fluctuate wildly across all threads from 50% to 100%, mostly within the 70% to 90% range, but now at 3850mHz.

This new behavior has added several hours to my encode times. I don't recall if I changed something, but what should I be looking at to correct this? Are there common culprits?

Thanks in advance,
Ethan

 

[Newtonius]

None of those should've affected the CPU speed (windows update maybe, but not likely) and BIOS cannot update itself. Most likely your CPU is switching between fastest cores to achieve higher clock speeds for single threaded performance. But for encoding you need to get the best Multi-threaded performance. I can't say why handbrake is not utilizing all cores at once

BUT:

Make sure you've updated your motherboard to the latest BIOS then download and install 'Ryzen Master' and 'HWinfo64' to see further in-depth details on what is happening with your CPU during high-load. In Ryzen master you can see core usage/speed/power-draw/etc. You can also manually adjust and overclock your CPU cores so all cores boost to a specified speed instead of fluctuating around. This is considered an 'all-core overclock'. You can also do this in the BIOS if you are technically knowledgeable about it, which I recommend you learn how to if you don't.

The base clock for the 2700X is 3.7GHz, the boost clock is 4.3GHz. On stock, at least 1 or two cores should reach 4.3GHz when on high-load. On 100% all the cores should get anywhere from 3.8-4GHz at least since it would be too hot and unstable at 4.3GHz all cores.

Which reminds me, make sure your temps aren't getting out of control. High temps will cause your CPU to throttle down the performance.

 

[below20hz]

None of those should've affected the CPU speed (windows update maybe, but not likely) and BIOS cannot update itself. Most likely your CPU is switching between fastest cores to achieve higher clock speeds for single threaded performance. But for encoding you need to get the best Multi-threaded performance. I can't say why handbrake is not utilizing all cores at once

BUT:

Make sure you've updated your motherboard to the latest BIOS then download and install 'Ryzen Master' and 'HWinfo64' to see further in-depth details on what is happening with your CPU during high-load. In Ryzen master you can see core usage/speed/power-draw/etc. You can also manually adjust and overclock your CPU cores so all cores boost to a specified speed instead of fluctuating around. This is considered an 'all-core overclock'. You can also do this in the BIOS if you are technically knowledgeable about it, which I recommend you learn how to if you don't.

The base clock for the 2700X is 3.7GHz, the boost clock is 4.3GHz. On stock, at least 1 or two cores should reach 4.3GHz when on high-load. On 100% all the cores should get anywhere from 3.8-4GHz at least since it would be too hot and unstable at 4.3GHz all cores.

Which reminds me, make sure your temps aren't getting out of control. High temps will cause your CPU to throttle down the performance.

Thank you for the response. I am baffled because I didn't think I changed anything that would change the core utilization. When first built, I left everything stock and it hit 3.7gHz at 100% across all cores - which is expected performance. I encoded a couple dozen movies (4K and 3D) over a month's time and everything went like clockwork. Now it's just acting weird and refusing to hit 100% across all cores.

However your comment about temps reminded me that I DID swap the parts to a new case over the holidays, and i noticed my temps are hitting above 70°C now, as high as 77°C. Previously in the original case the temps topped out at 70°C max. I didn't think 77° was high enough for the processor to throttle itself, but I guess I should look into that. I'm actually a little bewildered at the temperature change since the new case is bigger with better airflow. Maybe I need to reseat the cooler.

btw I am a former overclocker, so setting everything to an all-core OC is not a problem and as a last resort I will certainly use your suggestion, but I'd rather figure out why the change in behavior if I can, as I don't want to repeat it on my other rigs.

Thank you again for the response!

 

[Newtonius]

Thank you for the response. I am baffled because I didn't think I changed anything that would change the core utilization. When first built, I left everything stock and it hit 3.7gHz at 100% across all cores - which is expected performance. I encoded a couple dozen movies (4K and 3D) over a month's time and everything went like clockwork. Now it's just acting weird and refusing to hit 100% across all cores.

However your comment about temps reminded me that I DID swap the parts to a new case over the holidays, and i noticed my temps are hitting above 70°C now, as high as 77°C. Previously in the original case the temps topped out at 70°C max. I didn't think 77° was high enough for the processor to throttle itself, but I guess I should look into that. I'm actually a little bewildered at the temperature change since the new case is bigger with better airflow. Maybe I need to reseat the cooler.

btw I am a former overclocker, so setting everything to an all-core OC is not a problem and as a last resort I will certainly use your suggestion, but I'd rather figure out why the change in behavior if I can, as I don't want to repeat it on my other rigs.

Thank you again for the response!

Good to see you know what you're doing then. Yeah temps are probably the culprit then.

 

[below20hz]

Well it's not the temps.

I have taken it apart a few times now, and it's still doing the same thing, but I couldn't find my Noctua paste so I had to use some crappy Corsair junk from BestBuy and the temps are worse (actually a lot worse, hitting over 80°C). If it was a temp issue it would simply throttle my speeds even slower to maintain temps.

Also i completed another build with a Ryzen 2700X and the temps stay under 70°C, but that PC does the same thing when I encode with Handbrake or BD3D2MK3D.

The two PC's have different motherboards (MSI and ASUS) so I am wondering if this is possibly a Windows 10 issue? Any settings I should be looking at?

 

[superdavemaine]

I have an AMD 2700X with an Asus Hero VII motherboard clocked at 4GHz (built in overclock profile). I have a Noctua NH-D15 (single 140mm fan) cooler and five 140mm case fans.

I have also experienced CPU thrashing/throttling with Handbrake but on Linux (Ubuntu 19.10 with 5.5.10 kernel). I have installed the flatpak version of Handbrake if that makes any difference.

When I use slow/slower/very slow settings it throttles (100% down to around 50% or lower). Throttling seems cyclical. Each cycle (wave) is around 5 to 10 seconds.

Taking a look at /proc/cpuinfo I can see the frequency changes from 4GHz down to around 3GHz.

When using medium/very fast it does not throttle but the CPU is not pegged at 100%. It's more around 80% - 90% on all threads.

Ran the CLI "stress" test with 16 threads and it maxed the CPU to 100% without throttling.

I really hope I'm not thermal throttling, but in Linux, it seems rather difficult to get the temps for this CPU. The "stress" test indicates to me that I'm not thermal throttling.

 

[below20hz]

Yes you're right, I noticed the same thing: on slower settings the usage dipped much lower, on faster settings it stays within 90% for me. I'm 100% positive it's not a temp issue, I have zero issues maintaining 100% across all threads during stress testing and my temps are +8°C higher than when encoding in Handbrake. My brother's 3700x does the same thing. So given your observations and mine, it seems to me to be a Handbrake issue, which is a bummer because it used to hit 100% all threads and for no apparent reason it no longer does.

 

[superdavemaine]

@below20hz - What version of Handbrake are you using? I grabbed version 1.3.1 which is ahead of what the Ubuntu repositories have (I think Ubuntu repos have v1.2.x). Perhaps an earlier version might not have issues?

I was also going to give ffmpeg CLI a go. IIRC, Handbrake uses ffmpeg under the covers, so it might be a good test to see if the same issues happen when Handbrake GUI is taken out of the equation.

I think I forgot to mention this, but I was using the H.265 encoder coming from an H.264 source.

 

[below20hz]

I'm on 1.3.0 and iirc I did try switching to an older release but it made no difference. I only encode 4K in Handbrake using H.265, but i use H.264 when encoding 3D movies using BD3D2MK3D. If you fiddle around with it and find the culprit or even just eliminate some suspects, please report your findings. I sunk several weeks into it and gave up.

 

[superdavemaine]

Will do. After a little research, it seems that the very fast, fast, meduim, slow, etc settings actually add or remove certain optimizations. My guess at this point is one of those optimizations gets enabled when you get to the slow, slower, very slow, placebo settings.

 

[below20hz]

Well my bro just called me I'm on the line with him now. His 3700x was taking 3x as long as my 2700x to encode in BD3D2MK3D. Had him switch back from v1.19 to v1.17 (same as mine). Instantly cut his time in half, but still slower than mine. His 3700x is running 400mHz faster than my chip and that is very obvious in other applications, so it's gotta be some sort of setting or optimization as you said. If you figure it out I would love to know what you did. Thank you for sharing your thoughts!

 

[superdavemaine]

I ran a few tests using the command line ffmpeg. While I haven't nailed down exactly what is causing the CPU thrashing/throttling, I have some interesting data. Took a full length movie (2+ hours) and encoded the first 5 minutes in every ffmpeg preset.

Hardware

• AMD Ryzen 2700X
  • CPU Overclocked to 4GHz using BIOS preset
  • Noctua NH-D15 cooler
  • 8 cores / 16 threads
• 5 - 140mm case fans
• ASUS ROG Hero VII
• 16GB DDR4-3200
• Samsung 960 EVO NVMe SSD
• Air conditioned room at around 72F

Source File

• FPS: 23.976
• Resolution: 1920x1080
• Overall Data Rate: 38945kbps
• Video Codec: H.264
• Audio Codec: DTS-HD MA 7.1 channels @ 48kHz

Encoding Parameters

• ffmpeg v4.1.4-1build2 (installed from Ubuntu 19.10 repos)
• Video Codec: H.265 (-c:v libx265)
• Duration: 300 seconds (5 minutes)
• Frames: 7193
• CRF: 20
• Audio Codec: AAC @ 160kbps (-c:a aac -b:a 160k)

Example ffmpeg Command

ffmpeg -i input.mkv -c:v libx265 -preset medium -t 300 -crf 20 -c:a aac -b:a 160k output.mkv

Test Results

Preset	CPU Throttling	Encode FPS	File Size (kilobytes)	Encode Time (seconds)	Relative Performance
ultrafast	No	105	44,966	69	3.42x
superfast	No	87	56,201	83	2.84x
veryfast	No	48	92,719	149	1.58x
faster	No	48	94,751	150	1.57x
fast	No	41	94,358	178	1.33x
medium	No	31	106,954	236	1.00x
slow	Yes (mild)	14	109,022	532	0.44x
slower	Yes	3	126,059	2428	0.10x
veryslow	Yes	1.7	125,873	4169	0.06x
placebo	Yes	0.9	151,380	8408	0.03x

Once the CPU throttling starts, the encode time skyrockets. If "medium" preset is the normal (100% or 1.00x) then the fastest preset, "ultrafast", is 3.42 times faster than "medium". Whereas the slowest preset, "placebo", is 33 times slower. Even if you look at "veryslow", it's still 17 times slower than "medium".

What's unclear is whether it's the settings that are causing the large jump in encoding time, or if it's the CPU throttling, or both.

I found this reference while researching:
https://x265.readthedocs.io/en/default/presets.html

 

[superdavemaine]

I wanted to see if the CPU throttling issue occurred on Intel CPUs too. I happen to have a Dell Precision 7510, so I thought I'd give it a try. I actually did notice CPU throttling, but not nearly as dramatic as with the AMD CPU. With the AMD CPU the usage dropped to below 50%. On the Intel, it dropped to around 67%. When the Intel CPU wasn't throttling, its usage was almost always at 100%. The AMD CPU usage hovered around 90% when it didn't throttle.

This Intel laptop is running Linux Mint 19.3.

Intel Hardware

• Intel Xeon E3-1535M
  • Frequency: 2.9GHz base; 3.8GHz turbo
  • Sustained Frequency: 3.3GHz
  • 4 cores; 8 threads
  • 45W TDP
• 2 Laptop case fans
• 32GB DD4-2133
• Samsung SM951 NVMe SSD
• Same air conditioned room as the AMD test

Source File

• FPS: 23.976
• Resolution: 1920x1080
• Overall Data Rate: 38945kbps
• Video Codec: H.264
• Audio Codec: DTS-HD MA 7.1 channels @ 48kHz

Encoding Parameters

• ffmpeg v4.1.4 (installed from snap)
• Video Codec: H.265 (-c:v libx265)
• Duration: 300 seconds (5 minutes)
• Frames: 7193
• CRF: 20
• Audio Codec: AAC @ 160kbps (-c:a aac -b:a 160k)

Example ffmpeg Command

ffmpeg -i input.mkv -c:v libx265 -preset medium -t 300 -crf 20 -c:a aac -b:a 160k output.mkv

Test Results

Preset	CPU Throttling	Encode FPS	File Size (kilobytes)	Encode Time (seconds)	Relative Performance
ultrafast	No	62	44,966	116	4.04x
superfast	No	48	56,201	151	3.11x
veryfast	No	29	95,416	249	1.88x
faster	No	28	95,440	261	1.79x
fast	No	23	97,554	310	1.51x
medium	Yes (little)	15	116,908	469	1.00x
slow	Yes (some)	8	113,254	909	0.52x
slower	Yes (some)	2.3	137,765	3073	0.15x
veryslow	Yes	1.7	134,815	4368	0.11x
placebo	Yes	0.4	165,684	17081	0.03x

The Intel results are interesting. The CPU was able to sustain 3.3GHz across all cores. When CPU throttling occurred, even at its worst, it was not nearly as bad as the AMD CPU throttling at its worst. Throttling seems to start earlier than with the AMD CPU.

The FPS rates did not reflect the Intel chip's lower frequency was at 3.3GHz (AMD was at 4.0GHz) and fewer core/thread count.

AMD vs Intel FPS

Preset	AMD FPS	Intel FPS	AMD vs Intel
ultrafast	105	62	1.7x
superfast	87	48	1.8x
veryfast	48	29	1.7x
faster	48	28	1.7x
fast	41	23	1.8x
medium	31	15	2.1x
slow	14	8	1.8x
slower	3	2.3	1.3x
veryslow	1.7	1.7	1.0x
placebo	0.9	0.4	2.3x

I have been running other tests with different CRF and preset combos. So far, I've found that by setting the CRF low (say 10) then throttling started to occur at faster presets; as fast as "veryfast". So this leads me to believe it might not be a settings issue after all. It might be a throughput issue. Some hardware (CPU? Cache? Memory? SSD? Bus?) is limiting the encoding and causes the CPU to throttle.

I have noticed that on all the tests where the CPU throttled, the FPS was at or below the FPS of the source video. Not sure that has anything to do with it, but interesting.