Today I emailed David Anderson with the question why the option to use not all processors was changed to percentage of processors used instead of using an integer number as was the case in the older versions of BOINC.

According to David this was done to be ahead when it comes to having multiple systems with multiple cores, all different ones as well.

I am finding it fiddly. I'm assuming you do as well, knowing fully well that a lot of people out there find it fiddly. So this thread is here to find a possible better solution.

As I posted back to him, giving the Einstein ATLAS system with 5,368 cores as an example when using 50 cores only, one would have to input 0.9314556% to get it to use only 50 cores.

However, it is fiddly when it comes to using percentages as well, especially when used on only one machine with multiple cores. The example I gave with more than 1000 cores just goes to show how fiddly that will be. And what will that number (0.9314556%) do to a machine with lesser cores that happens to be on the same account?

You stepped away from using percentages on the resource share. Perhaps that something similar should be done here as well. Although you might best shy away from setting these numbers in the web-based preferences all together. Have it only be set through the local preferences, so it can be set per machine, or give a fixed amount of CPUs one can set and put those as options on the web-based preferences.

So the question really is, how would you solve this problem?

Poll:
1) Do you want that BOINC gives fixed amounts of percentages you can use only?
2) Do you want to go back to using fixed integer numbers for the amount of CPUs, possibly with the added ability to set your own percentage?
3) Should BOINC no longer use the web-based prefs for this, but instead only let it be done through a setting in the installer and BOINC Manager? (BOINCCMD for the CLI)
4) Shy away from fixed numbers and percentages, but use option X? What is your option X?
5) Keep using the present system, there is no other way of logically doing this.

Hopefully if we come up with a better solution, an easier solution preferably (think newbie, non-geek), we can make BOINC that bit better.

---

2) Do you want to go back to using fixed integer numbers for the amount of CPUs, possibly with the added ability to set your own percentage?

6) (or sort of 2) One selector to choose between an integer and a percentage value, next to it one input field for the integer/percentage value.

On per-host preferences, when invoked for the first time, on small amount of cores it could default to nCPUs, on a large machine (maybe > 16) to %CPUs,

Peter

I think most people with a mixed bag of hardware will already use local preferences per BOINC installation. The web based location settings are at too coarse a granularity to handle wide mixes of 1,2,4,8... core set ups. I prefer deal in number of cores on a per machine basis, though I can see the attraction of a "percentage use of my computer" value for a web based default for new users.

So I vote with pepo's option (6) which potentially allows either to be used.

Andrew

The simplest way would be to enter the number of cores they want to use (as it did in BOINC 5.10.45).

If you want to make it graphical have a slider bar from 1 to the total cores in the machine. So on a Core 2 Duo (or similar) you'd only be able to select 1 or 2. On a Core 2 Quad (or similar) allow selection of 1 thru 4.

As I understand it ATLAS appears as 1342 x quad-core machines, so each machine could only go up to 4 and the others simply wouldn't run BOINC. Perhaps if they ever get Superhost done we could tell it a max of 50 of the available 5368 cores?

* ATLAS figures as mentioned by Berndt on Einstein@home (give or take a few administration nodes)

---

MarkJ

Today I emailed David Anderson with the question why the option to use not all processors was changed to percentage of processors used instead of using an integer number as was the case in the older versions of BOINC.

As I pointed out to David Anderson at the time, the new preference has replaced the old without any form of backward compatibility. The old preference is simply ignored by new clients. Given that not all projects have the same preference handling code, and there is no standard mechanism for handling unknown preferences - there is a huge potential for frustration here.

I *think* my preferred option is to use a specific number of processors unless a percentage is specified instead. But I am open to other opinions....