Message boards : BOINC client : Why not use whole numbers instead of % for multiprocessor usage?
Message board moderation
Previous · 1 · 2
Author | Message |
---|---|
Send message Joined: 25 May 09 Posts: 1304 |
Here is a prime example of your lack of understanding of how the science applications work - one may set a "use x% of a CPU" per GPU task, but that is only an rough guide - the GPU will use as much CPU resource as it needs, and that is out of the control of BOINC. The how much and when will be very dependant on the application, and is out of the control of BOINC. But we digress - you are obviously in a minority, so just back down admit that it is you who has a problem with lack of common sense, the join the development team over on GitHub where the majority of them live, or cut you own version of BOINC. |
Send message Joined: 25 May 09 Posts: 1304 |
BOINC does NO processing and has never claimed to do any. Processing is all down to the projects, this includes the actual way work is distributed between the GPU and the CPU - from memory you have been in the conversations where this has been explained. You assume that because something hasn't been designed to do what you want it to do it must be wrong. If you think I'm wrong, tell me why. Count how many people have supported you in this discussion to date = ZERO Thus you are on your own, or at least in a very small minority. Further read and understand the suggestions that have been made in thhis thred, you will find they work very well for the vast majority of users. As I've said before, this forum here is labelled for discussions on Boinc Client and how it can be improved. If the developers don't read it, I don't care. You would rather whine and wind people up rather than try to move things in the direction you desire and ignore the advise to go and join the place where the majority of the developers watch - if you want to influence the direction of where a development heads you have to be in the right place to do that influencing. It is worth pointing out that some of the changes over the years have come from people who had a particular requirement and they cut their own version to prove their point. Why don't you try that approach, if it works well and proves to be a useful feature to have the advantages you posit to have. |
Send message Joined: 29 Aug 05 Posts: 15574 |
The BOINC devs (when they were still just David, Charlie and Rom) used to look here, but that time is long past. Rom no longer develops BOINC, Charlie has retired and David doesn't even look into things when I ask him to. Development of BOINC has moved to community based development and the community has chosen that their favorite platform for communication is Github, although you ought to be able to get answers on the BOINC email lists as well. So, Github here: https://github.com/BOINC/boinc/issues Email lists there: https://boinc.berkeley.edu/trac/wiki/EmailLists These forums state on their index: These messages boards are for the discussion of BOINC, not projects.Not developers. Although even those sometimes pass by, if you're lucky. And some may already have answered. |
Send message Joined: 25 May 09 Posts: 1304 |
...and sadly it is the only way to get through to the developers :-( |
Send message Joined: 8 Nov 19 Posts: 718 |
And ineffective. Developers will only see bugs and feat requests. Not how much it is desired for in the community, or how many people ask for these features. Unless the idea strikes a developer as a great and feasible (think easy and fast) way to fix things, it's not going to get done...😔 |
Send message Joined: 28 Apr 20 Posts: 12 |
Count how many people have supported you in this discussion to date = ZERO I don't need it for myself, but I can see, that this would be helpfull for others. So the number of other supporters will now be ONE. But this should also not be only a question of how many people support it. It could be also just a helper for the input. There could be a slider in the steps of number of cores and the value to save could still be the percentage. The important questions should be: Does it help? Yes, as described enough above. Does it hurt somehow anyone? I can't see any disadvantages. What is the needed time to implement? As a developer I can say: For a person, who allready code at this application, that should be a work of about 30 minutes to an hour. |
Send message Joined: 25 May 09 Posts: 1304 |
The ideas guy can often make the best test guy - he knows what he wanted and so can make sure the developer does what was wanted.... |
Send message Joined: 28 Apr 20 Posts: 12 |
To clear some things: Yes, I'm a developer, but I'm curently not develop at BOINC. So I would have to "learn" it first. |
Send message Joined: 25 May 09 Posts: 1304 |
Thanks, you've thought about it for a few days and parked it. Learning how BOINC is put together is not a five minute job as the structure and annotation is very variable, some is well structured and well documented, while some is a "bowl of well chewed spaghetti". |
Send message Joined: 5 Mar 08 Posts: 272 |
Perhaps a better suggestion. It could have a slider with 0 to 100%. As you slide it display the percentage above the slider and the number of cores out of the total available underneath. You don’t need to change the core client to implement it, it’s a GUI change. I believe there was mention of a developer looking at the GUI with a view to updating it. MarkJ |
Send message Joined: 26 Feb 07 Posts: 71 |
The Android app, for all it's other problems, does actually manage to do this ! I currently run various BOINC projects on 2 systems, an 8 core 14" screen Android tablet, and a Windows 10, 10" screen, convertible netbook, with 4 cores. On both systems, I occasionally change the number of Cores in use, according to other priorities. I find it easier to select 2, 4, 6, or 8 on the Android device, than 25, 50, 75 or 100 on Windows I usually restrict the Windows system to 75% with the Intel GPU in use too. |
Copyright © 2025 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.