Limit CPU Speed

Message boards : Questions and problems : Limit CPU Speed
Message board moderation

To post messages, you must log in.

AuthorMessage
scottneh

Send message
Joined: 2 May 20
Posts: 1
Message 98281 - Posted: 2 May 2020, 18:08:21 UTC

Hi all, I have been running BOINC SETI@home for 15 years. I really like setting my machine up to contribute but I having an issue on a new build. I just finished a dual Xeon 4216 machine on an ASUS WS C621E SAGE, 128 GB Ram and three Tesla K80s. I'd like to keep the CPU speed limited to the factory recommended speed of 2100MHz but it looks like when I run BOINC on this machine, it drives the clock frequency up to 2700MHz. I have not yet rigged up my cooling system to handle this. Nominally the CPUs sit at 35 to 40 deg C but with BOINC running its pushing up to 60 dec C and all sorts of alarms start going off on the cooling system.

Does anyone know if there is a way to limit the clock frequency within the BOINC software?
ID: 98281 · Report as offensive
Richard Haselgrove
Volunteer tester
Help desk expert

Send message
Joined: 5 Oct 06
Posts: 5081
United Kingdom
Message 98282 - Posted: 2 May 2020, 18:31:30 UTC - in response to Message 98281.  

No. That would be a function of the operating system, the BIOS, or a motherboard utility.
ID: 98282 · Report as offensive
Profile Dave
Help desk expert

Send message
Joined: 28 Jun 10
Posts: 2536
United Kingdom
Message 98283 - Posted: 2 May 2020, 18:33:03 UTC - in response to Message 98281.  

It won't do the speed but you can limit the percentage of cpu time BOINC uses. Don't know how well that works.,Never having used a dual chip machine I don't know if you can limit the number of cores on each chip? Pretty sure someone will know the answer to that here though.
ID: 98283 · Report as offensive
ProDigit

Send message
Joined: 8 Nov 19
Posts: 718
United States
Message 98306 - Posted: 3 May 2020, 17:47:54 UTC

Depending on what project, you may need to run your CPU this high just to feed the GPUs.
Sometimes setting the CPU in BoincManager to 99% helps alleviate some excess heat.
ID: 98306 · Report as offensive
Ian&Steve C.

Send message
Joined: 24 Dec 19
Posts: 228
United States
Message 98307 - Posted: 3 May 2020, 18:06:54 UTC

to answer your actual question, disabling the Intel Turbo boost in the BIOS should keep the processor at its base frequency.

all modern Intel chips have several levels of clock speed boost under certain conditions, some based on time limits, some based on thermal/current limits, as well as number of active cores. most of these modern chips will only run the base clocks if you are thermal throttling the thing (like 80-90C).
ID: 98307 · Report as offensive
Richard Haselgrove
Volunteer tester
Help desk expert

Send message
Joined: 5 Oct 06
Posts: 5081
United Kingdom
Message 98309 - Posted: 3 May 2020, 18:56:02 UTC - in response to Message 98306.  

Depending on what project, you may need to run your CPU this high just to feed the GPUs.
Sometimes setting the CPU in BoincManager to 99% helps alleviate some excess heat.
How? Pray explain?
ID: 98309 · Report as offensive
Ken Sharp

Send message
Joined: 14 Oct 08
Posts: 15
United Kingdom
Message 98325 - Posted: 4 May 2020, 11:11:40 UTC

Would limiting the processes with cgroups to, say, 90% prevent the turbo boost from occurring? It would allow other non-limited processes to use the boost as needed, in theory.

I haven't tested this, though I do have a machine I could test it on, so may do this at some point.

It might depend on the scheduler, and changing that for a general purpose computer isn't usually a great idea.
ID: 98325 · Report as offensive
ProDigit

Send message
Joined: 8 Nov 19
Posts: 718
United States
Message 98338 - Posted: 5 May 2020, 17:39:29 UTC - in response to Message 98309.  
Last modified: 5 May 2020, 17:43:38 UTC

Depending on what project, you may need to run your CPU this high just to feed the GPUs.
Sometimes setting the CPU in BoincManager to 99% helps alleviate some excess heat.
How? Pray explain?

Some projects need high CPU activity to feed GPUs, especially RTX GPUs.
Setting CPU to 99%(or lower) in Windows power management can prevent your CPU to reach the highest C state.
In Linux it's a bit more complicated.
In Boinc MGR, setting your CPU to 99% instead of 100%, will free up 1 core from crunching, resulting in perhaps the same, or faster CPU core speeds, but slightly lower temps (because you're running 1 CPU thread less).
ID: 98338 · Report as offensive
Richard Haselgrove
Volunteer tester
Help desk expert

Send message
Joined: 5 Oct 06
Posts: 5081
United Kingdom
Message 98340 - Posted: 5 May 2020, 18:00:08 UTC - in response to Message 98338.  
Last modified: 5 May 2020, 18:09:53 UTC

Some projects need high CPU activity to feed GPUs, especially RTX GPUs.
...
In Boinc MGR, setting your CPU to 99% instead of 100%, will free up 1 core from crunching, resulting in perhaps faster CPU core speeds, but slightly lower temps (because you're running 1 CPU thread less).
I was afraid you thought that. No. It's the other way round.

Say, for example, you have a quad-core CPU plus one or more GPUs.

The BOINC client (not the manager) allows over-commitment up to 4.99(999?) CPU cores - I'm not sure how many decimal places are significant. Say it's 4.99, as in your advice.

That will allow all four cores of the CPU to run a full CPU app, plus the asserted 99% support required by the GPU app. If the GPU app really is that greedy (not all are). you will see the 'pure CPU' applications drop to around 80% throughput.

If, on the other hand, you set a single GPU app to use 100% of a CPU, or several GPU apps to use %ages adding up to >= 100%, then BOINC would be entering forbidden territory with an over-commitment of 5 or more CPUs. At this point, BOINC will stop one of the CPU apps from running.

In short:
Setting GPU to need 1% to 99% --> 4 CPU apps running, plus 1 GPU app - over committed, liable to thermal throttling.
Setting GPU to need 100% -->3 CPU apps running, plus 1 GPU app - fewer tasks, but cool, quiet, and efficient.

It's that final tick from 99% to 100% that makes the difference.

Edit - we've been using the phrase 'reserve a core' for GPU support to describe this process at SETI, for at least 8 years.
ID: 98340 · Report as offensive
ProDigit

Send message
Joined: 8 Nov 19
Posts: 718
United States
Message 98372 - Posted: 8 May 2020, 12:34:58 UTC
Last modified: 8 May 2020, 12:39:39 UTC

Most projects have GPU values set to 0.97cpu or less.
So setting CPU to 99% in manager, will free up 1 core, to run the .97 GPU WU, and there won't be any overcommitment.
To reserve 1 CPU per GPU isn't necessary. Not for AMD, not for Nvidia.
It is in some cases better in Windows (I'm using Linux), however the 80+ remaining computation power of the CPU thread is better utilized crunching, than used for sending idle data (like in the case of Nvidia drivers under Windows).


Some of these GPU projects, actually only use .15 CPU instead of the assigned .97 CPU values.
The CPU overcommitment is only little. Releasing 1 core (setting CPU to 99%) will release 1 CPU core, and run the 15% of the GPU WU in it, essentially leaving 85% of the core unused.

Setting GPU to 1 core might be the correct way of doing this, but it's not feasible when running multiple PCs and multiple GPU projects, not to mention that you'd have to adjust these settings to all new projects and new batches as well.

For that reason, setting CPU values in manager to 99% is a much more effective and efficient way.

I would never go and adjust GPU settings to 1CPU for all GPU projects I'm running, on all my PCs in app_config.xml!

What would be the correct way to do it, is adjust each GPU WU to what it actually uses (eg: set 0.97cpu values of GPU WUs, to 0.15, if that's what they really use).
However, this procedure faces the same tiresome work as setting each GPU WU to 1CPU.
ID: 98372 · Report as offensive

Message boards : Questions and problems : Limit CPU Speed

Copyright © 2024 University of California.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.