Looking for feedback - possible revision to preferences
4 Aug 2022 3:18:23 UTC
Topic 227924
(moderation:
Hello,
On the development side of BOINC, some of us are looking at making some changes to the settings. There are two parts to this that would change:
1. We are looking at adding settings for the amount of CPU cores used and percentage of CPU time that would be used in two cases: When the computer is in use and when it is not in use. 'In use' being the same definition as it is in the settings. Additionally, the setting for what percentage of non-BOINC CPU usage will now be able to have a different setting between in use and not in use as well.
2. The arrangement of the settings will be different. The rest of the settings will be still available, but in a different heading and location. For example, the settings above would be under a "when computer is in use" and "when computer is not in use" header. Other settings such as percentage of memory will be added under each of those headers, instead of under a disk and memory header.
Of course, a picture tells the story a bit clearer. Here are some screen captures of what it will look like:
Any kind feedback from the community, both positive and negative, would be appreciated. Thank you!
Bill
There was an email
)
There was an email circulating among a small group of developers yesterday, to which I replied:
I'm thinking about the deployment consequences for all of this.
The SETI@home test server deployment - provisionally - looks fine, and is live for testing purposes. Modifications are saved on the server.
But as yet, we can't even see the effects in the sched_reply file: attempts to update result in
03/08/2022 09:24:49 | SETI@home | Scheduler request failed: HTTP file not found
That needs to be resolved before the new sched_reply can be read by an updated client, and transferred to global_prefs.xml
As noted by David, the same changes will need to be included in the client handling of global_prefs_override.xml, and ultimately a manager GUI for the new values will be needed.
But my major concern is the cross-project promulgation of the new format. Projects don't all update their server code synchronously, and some projects - notably Einstein - use non-BOINC xml handlers which enforce different verification policies. I worked on a problem in 2016, where Einstein was losing data because of a formatting error in the generic BOINC server code (https://einsteinathome.org/content/invalid-global-preferences-problem?page=1#comment-150509). We need to work with (at least) the Drupal maintainers to ensure a smooth transition.
Good point, Richard. I have
)
Good point, Richard. I have similar concerns for minor items I would like to fix as well.