What's the limit for concurrent CPU tasks?
1 Oct 2019 18:04:39 UTC
Topic 219694
(moderation:
With no GPU tasks running, would it be feasible to run O2AS20-500 GW CPU tasks on all (or nearly all) threads with the latest generation of desktop CPUs? For example, Intel i9-9900K with 8 cores-16 threads or Ryzen Threadripper 2950X with 16 cores-32 threads? Is there a limit to running concurrent CPU tasks?
Ideas are not fixed, nor should they be; we live in model-dependent reality.
As far as I know BOINC does
)
As far as I know BOINC does not have a cpu limit. But GPUGrid might.
I have gone to 70%
)
I have gone to 70% utilization on my server (16 out of 24 cores) with no issue. I wouldn't push it much further that that without installing the second power supply and configuring for load sharing. Power consumption and cooling might be the limiting factors.
Bear in mind, I have two
)
Bear in mind, I have two separate processors in my box, 6 physical cores each. My rule of thumb is one physical core per WU to be safe. Anything else might require supplementary cooling.
cecht wrote:With no GPU tasks
)
As far as I remember there is no limit other than what you set up your max # of days is set out. That being said. It's possible to download several THOUSANDS of work units which will probably ended up timing out. Best strategy is to limit BOINC to 1 day worth of work.
The second issue is going to be keeping that CPU cool. Best to make sure you have either an AIO loop or custom water loop cooler with that issue.
cecht wrote:Is there a limit
)
The limit is just the number of threads that BOINC can (or is allowed to) see. The CPU will be using 'self-preservation' mechanisms (if necessary) if you fail to provide a cooling solution capable of keeping the die within critical temperature limits.
In 2008, I built 6 machines with Q6600 quad core CPUs. This was well before any GPU apps came along and they were 'flogged' for many years running CPU tasks on all cores where reported temperatures were often in the high 80s to low 90s C. None of those CPUs have ever failed, nor do I recollect ever seeing any evidence that they were invoking their self-preservation mechanisms. I gave away running CPU tasks on them a couple of years ago but they still run correctly, supporting GPU crunching. The motherboards have needed quite a few repairs, though :-).
You specifically mention the continuous GW search so I guess the likely reason for thinking about high thread count CPUs is probably related to legitimate concerns about how long it may take to arrive at a stable and efficient GPU app. My advice is to hasten slowly :-). At the end of the day, my gut feeling is that the problems with the GPU app will get resolved and the efficiency will be improved to the point that it can be demonstrated that a lower cost, lower thread count CPU will be able to support a GPU to give a more efficient and more cost effective solution than a monster thread count CPU will. It probably already does if the tasks would consistently validate :-).
Cheers,
Gary.
Keith Myers wrote:As far as I
)
Good to know, but I was thinking more on the hardware and host system side. I'm wondering whether, for example, with 30 of 32 threads grinding away on GW tasks, do completion times become so long as to not make it viable to run so many concurrent processes (I see times increase on my 4-thread system with each thread added for concurrent tasks), or whether CPU heat dissipation becomes a problem. I don't know how to query the database to see who is actually running big multi-core CPUs all-out on concurrent CPU tasks.
Ideas are not fixed, nor should they be; we live in model-dependent reality.
Gary Roberts wrote:You
)
Bingo! Yes, true, but I'm also mildly curious about how well multi-multi-core systems actually work for E@H. I didn't see your reply before I posted my reply to Keith, so otherwise would have modified it somewhat. Nevertheless, thanks for info on CPU temps and prognostications on GW GPU apps. :)
Ideas are not fixed, nor should they be; we live in model-dependent reality.
Zalster wrote:[...That being
)
Ah, yes, I hadn't thought of download and timing out issues. Water cooling does make sense. I had to look up AIO: All-in-One! Good to know.
Ideas are not fixed, nor should they be; we live in model-dependent reality.
Matt White wrote:I have gone
)
Good info! Thanks.
Ideas are not fixed, nor should they be; we live in model-dependent reality.
cecht wrote:Good to know, but
)
I tried that experiment about two weeks ago, dropping my CPU utilization to 35% (6 out of 24 cores). I did not see an appreciable decrease in crunch time for the CPU WUs. But my RAC dropped during that period. Of course. with two physical CPUs, we might be comparing apples to oranges. Twin CPUs might work in tandem, negating most of the additional delay.
Looking at the temperature graph, the crunching process seems to be somewhat more complex than one core per task, even with Process Lasso assigning cores to WUs. I suspect what is really going on is, the CPU cores all work in concert, based on the utilization factor, and CPU affinity settings. I wonder if I would see different behavior if Hyper-threading were disabled? The obvious first effect is, I would be limited to 11 CPU and 1 CPU for GPU support. It would be interesting to see the temperature profile.
In December, I am looking to acquire a pair of HP Z420 boxes, slated for surplus. One of them will replace my LINUX box for BONIC crunching. These boxes have 8 GB of memory and have Xeon 2.67 GHz Quad core processors. The GPU slot is PCIe 3, which should allow my RX-460 GPU a wider bus to work with. Once configured, I may re-enable CPU tasks on that box and run the above experiment on a single CPU.