Specifically assigning cores to projects

Message boards : Questions and problems : Specifically assigning cores to projects
Message board moderation

To post messages, you must log in.

AuthorMessage
Bryn Mawr
Help desk expert

Send message
Joined: 31 Dec 18
Posts: 284
United Kingdom
Message 98764 - Posted: 24 May 2020, 0:51:28 UTC - in response to Message 98761.  

I have an old machine with 4 cores and limited RAM (the RAM is not upgradable, as it's at the motherboard's maximum).

I wish to run Rosetta on it, but the RAM means I can only do 3 of these at once. So I'd like to run 3 Rosetta tasks and 1 Universe task.

Is there some simple way to just tell it this? 3 of these and 1 of those?

I seem to have to plaster about with limiting concurrent numbers of tasks for Rosetta to 3 (otherwise it runs 3 and a 4th just sits there saying waiting for RAM, leaving a queued Universe doing nothing), then hoping it will have a Universe left over to fit in the remaining core, but then I have to mess around with weightings across the projects so one queue doesn't run out. Am I missing the obvious here or is Boinc really this messy?


If it is physically incapable of running 4 Rosetta but tries to then I *would* limit it. Simply create an app_config.xml file in the project directory containing :-

<app_config>
<project_max_concurrent>3</project_mac_concurrent>
</app_config>
ID: 98764 · Report as offensive
Bryn Mawr
Help desk expert

Send message
Joined: 31 Dec 18
Posts: 284
United Kingdom
Message 98772 - Posted: 24 May 2020, 9:04:46 UTC - in response to Message 98765.  

I have an old machine with 4 cores and limited RAM (the RAM is not upgradable, as it's at the motherboard's maximum).

I wish to run Rosetta on it, but the RAM means I can only do 3 of these at once. So I'd like to run 3 Rosetta tasks and 1 Universe task.

Is there some simple way to just tell it this? 3 of these and 1 of those?

I seem to have to plaster about with limiting concurrent numbers of tasks for Rosetta to 3 (otherwise it runs 3 and a 4th just sits there saying waiting for RAM, leaving a queued Universe doing nothing), then hoping it will have a Universe left over to fit in the remaining core, but then I have to mess around with weightings across the projects so one queue doesn't run out. Am I missing the obvious here or is Boinc really this messy?


If it is physically incapable of running 4 Rosetta but tries to then I *would* limit it. Simply create an app_config.xml file in the project directory containing :-

<app_config>
<project_max_concurrent>3</project_mac_concurrent>
</app_config>


Yes, that's what I did. It succeeds in preventing a fourth Rosetta from running, but the trouble is, it doesn't always fill the unused 4th core. It should be putting a Universe in there (which takes very little RAM), but unless the project weights are just perfect, then it may only have Rosettas queued, and just leaves the core idle. Or if the weights are slightly out the other way, it ends up running more than one Universe. There must be a simpler way than this, why is Boinc written so badly?


Give it time to settle down (at least a week) and it should run 3 and 1 as you want it to.
ID: 98772 · Report as offensive
robsmith
Volunteer tester
Help desk expert

Send message
Joined: 25 May 09
Posts: 1283
United Kingdom
Message 98773 - Posted: 24 May 2020, 9:54:28 UTC

If you try to fully commit the CPU to doing project work you will find that the operating system will start to kick things out so it can do its work. Thus every time the OS needs to transfer data between say the network interface to a running task you will cause one of the running jobs to get sidelined briefly, it is far better to make sure that one core is always available to the OS. This will have two affects, first the operating system will be able to do all the stuff it needs to without having to fight for resource, and second you will almost certainly find the applications will probably run a bit quicker as they aren't having to duck out of the way to let the OS do something - and this is, in my experience more so on low performance systems.
ID: 98773 · Report as offensive
Profile Jord
Volunteer tester
Help desk expert
Avatar

Send message
Joined: 29 Aug 05
Posts: 15477
Netherlands
Message 98785 - Posted: 24 May 2020, 13:50:28 UTC - in response to Message 98765.  

There must be a simpler way than this, why is Boinc written so badly?

This shows how to get the source code;
This shows how to compile it

Go and make it better than it was, if you find it written so badly. It's only 512,227 lines of code for all of BOINC. A doozy.
ID: 98785 · Report as offensive
Profile Jord
Volunteer tester
Help desk expert
Avatar

Send message
Joined: 29 Aug 05
Posts: 15477
Netherlands
Message 98788 - Posted: 24 May 2020, 14:09:56 UTC - in response to Message 98787.  

Firstly, since I didn't write it, it would be monumentally simpler for someone who wrote it to change it.
You know where to find them: https://github.com/BOINC/boinc/issues
ID: 98788 · Report as offensive
Profile Dave
Help desk expert

Send message
Joined: 28 Jun 10
Posts: 2515
United Kingdom
Message 98789 - Posted: 24 May 2020, 14:34:58 UTC

Firstly, since I didn't write it, it would be monumentally simpler for someone who wrote it to change it.

However most of the original writers are no longer around either.
ID: 98789 · Report as offensive
robsmith
Volunteer tester
Help desk expert

Send message
Joined: 25 May 09
Posts: 1283
United Kingdom
Message 98793 - Posted: 24 May 2020, 15:00:05 UTC - in response to Message 98792.  

Given you don't have the skills required to do the changes that you desire then it might be worth talking to someone who thinks they sort your idea for number of cores used instead of percentage of cores used.
Here's the link to one of his posts where he suggests he has the skills, and it should take between 30 minutes and an hour:
https://boinc.berkeley.edu/dev/forum_thread.php?id=13720&postid=98777
ID: 98793 · Report as offensive

Message boards : Questions and problems : Specifically assigning cores to projects

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.