Personally, for BOINC purposes, I wouldn't worry too much about the difference in RAM speeds. If it was a gaming rig I'd be looking into it more, but I doubt it'll have any appreciable impact on BOINC throughput.

Completely up to you Bobby. If it was me I would be running it at 3200 MHz because that's what I paid for.

I've not run a desktop AMD CPU in a long time, but if it's anything like my experience with Intel systems, you likely need to have a play around with the XMP profile settings, or whatever the AMD equivalent is. Also probably worth checking that the RAM is on the hardware compatibility list for the motherboard - if it is, perhaps drop a ticket to the mobo manufacturer asking for guidance?

It is, but I believe there are official tools for Windows that allow some BIOS tweaks (such as TPP/TDP and/or ECO mode) without a reboot... As a Linux user, I'm still waiting patiently for something official that does the same for my 3700X -- I suspect it'll need a far newer kernel than I've got at present :-)

By the way, I used the BIOS to cut TPP on my Ryzen to 80W (apparently, normal for 65W CPUs is 88W) and that got me plenty of reduction in both voltages and temperature without any noticeable degradation in performance. I suspect the ECO mode setting takes TPP quite a bit lower than that :-)

Cheers - Al.

P.S. On a standard Ubuntu system it's fairly easy to downclock a [complete] CPU without rebooting, so temperature management is currently a lot easier on my older systems...

The technique I use has worked on Ubuntu systems for quite a few years, but if you have major differences in your set-up it may not work (and I have no idea if it works on very modern Intel CPUs with the two types of core).

Check in /sys/devices/system/cpu/ for a subdirectory called intel_pstate - if it doesn't exist this won't work :-) Check also in /sys/devices/system/cpu/cpufreq/policy0/ to see what scaling governors are available and which one it's using by default -- all mine have always used powersave so I don't know if it still works with performance governor.

The intel_pstate directory contains various "files" that relate to CPU performance -- in particular, there is one called max_perf_pct and another called no_turbo. The names are fairly self-explanatory, I think...

As examples of what I've done, I have three Intel systems of roughly equal vintage, an i7-7700K, an i5-7600 and an i5-7200U (laptop):

I am quite happy to run the laptop at above its Turbo clock rate but I don't want it running flat out as it runs too hot for my liking, even in winter-time. So no_turbo=0 and max_perf_pct set to 93 (for 2.9GHz) most of the time, but I currently have it at 85 (for 2.7GHz) -- laptop cooling, wazzat? :-)

The i5-7600 is in a quite confined case that gets hot even in relatively low ambient temperatures, so I've always kept its clock at 3.5GHz (max_perf_pct=84) or, occasionally, below.

As for the i7-7700K, I have no_turbo=1 and I never let the clock above 4.0GHz (especially if I'm running MCM1 or SCC1, which both run cores hotter!) At the moment, I'm running it at 3.7GHz (max_perf_pct=82).

One might change the value with (for instance)

    sudo echo 82 > /sys/devices/system/cpu/intel_pstate/max_perf_pct

This is, of course, a bit of a nuisance if one has to do it at each restart, so I use sysfs to get the values set at boot time (having confirmed that they work as expected...) -- my /etc/sysfs.conf file has a range of possible settings, mostly commented out, which I tweak whenever I change the settings manually, ready for the next restart...

The above works for me; however, that's no guarantee that it'll work for you, or that it'll do what you want it to -- if so, it might serve as a start-point for some research anyway. It's certainly a better way of keeping laptops cool with BOINC than getting BOINC to keep stopping and starting tasks (I wonder if Intel Macs can do the same under Darwin?)

Anyway, I hope that is of interest :-) [I also hope there aren't any typos that I've missed!]

Cheers - Al.

P.S. I'm fairly sure there ought to be the possibility of doing something vaguely similar for AMD chips on Linux (even if it is just control over power rather than clocks); data centres (and some workstation users) might like the ability to tune in an emergency without relying on the system throttling itself and without needing reboots (and they won't all be running Windows!...)