BOINC Wish List

The big idea of BOINC is that when a project is down you could always run the other project, right? So my suggestion would make this one automatic.

Here's the rundown:
prefs =>
1.) Ready to start = 0; choice: Yes / No
2.) 0 WU left; choice: Yes/No
(if 1 yes, 2 should be no and vise versa)

3.) download extra WU? choice: Yes/ No
(yes will download n WU where n is No#ofCores)


-Activate 2ndary priority project (or 3rd to nth project) only if prefs are true.
-2ndary will only download an exact amount of WU base on the computers number of cores; if 3rd pref is yes, then it will download extra.
-CPU and GPU should have its own priority - meaning there could be 2 first priority project, 1 cpu and 1 gpu.
eg.
CPU 1st = WCG, CPU 2nd = Rosetta
GPU 1st = Seti, GPU 2nd = GPUgrid
-2ndary will stay active until 1st is alive and got WUs (No#ofCores).


MY goal here is to get high efficient rigs (for users that dedicate its resource on one project). Cache of 10 days or less is not a solution; the more cache you have, the more resources it occupied, thus less efficient. For example, 1%/day of a computer resource is allocated for cache, sure its small but when you see the big picture like multiply that for a yr and also multiple that for all your rigs then its a big waste.
____________

[19573] adds the <exclusive_gpu_app> option to a future version of BOINC.
____________
Jord

- BOINC FAQ Service
- BOINC User Wiki

Real is just a matter of perception.

Thanks for this (BOINC v6.10.32):
client: if a project has zero resource share, treat it as a "backup project": fetch work from it only if there is an idle instance and no other projects have work.
____________

I think it will be useful to do a automatic or manual task priority setting. Right now i have complicated task with deadline at 12.02.2010 and more simple tasks with deadline much later. Obviosly, my comp should set 1st priority to task with closer deadline, but i cannot do that without stopping all other tasks.

I understood. So i think it still can be done when i have only 1 project bound to and multiple task pieces of this current project. When you download different project task, sheduling automatically returns to common. This balance will be optimum, isnt?

I understand and must agree.

As a new user, I'm not going to pretend to know all the ins and outs of how the scheduler works, how the client behaves in relation to the server load, or any of that, but I am going to put my 2 cents worth in anyhow. :)

Many years ago, I used to write communications software for the OS9 operating system / 68B09E processor(yeah, the Tandy COCO III), and what I found is that the client can only be as intelligent as the patients of the end user. If you add too much code to the client to compensate for end user OCD, the client becomes inefficient and bogged down. If you add too much code to the server to compensate for the same, the server becomes bottlenecked in the same fashion.

What is really needed is to reiterate to the enduser that constantly pressing update buttons and such really won't help if the message file states a server is not responding, or how little it actually improves their stats in the long run. Just my thoughts....

An example of end user OCD is a prompt I had on my old BBS I ran for the user at login. It simply stated "press CTRL-ALT-DEL for express login"... I know, a mean trick to play on the DOS machines, but funny to watch none the less as they get booted and their machine resets. In any event, those are my simple thoughts. Have a great day everyone!

. . . "press CTRL-ALT-DEL for express login" . . .

Hi foks, I have 2 suggestions that maybe can help in lowering the amount of access requestes and thus the communication traffic with SETI.

1 - Provide the BOINC sotware with a more acurate gear to detect wich type of WUs are needed to download.

Since I have just one video GPU board and 8 CPUs, I have always a huge amount of cuda units ready to start and I fequently run out of CPU work and my boinc still asks for more CPU AND GPU work.

Consequently my pc is always asking for more and more and this is a lot of traffic and a waste of CPU resource.

I guess that using the client stats available, maybe it's not difficult to provide boinc with a more accurate gear to manage the communication.

2 - Make the upload to be done in one shift.

Today we have a 3-hit-uploading: a)we first upload and b)report and c)ask for update to see the updated numbers!

I don't leave my computer with communications open all the time because it would receive a lot of bad units that are beig recycled and a mess of hi priorities and I allow communications just once-a-day during the week and maybe twice in the week-end: at these momments I want to know the numbers, since this is the fun and then comes the third hit. MAYBE the site could receive all the uploads in a kind of "updating session", make the report internally and update the numbers for the customer at the end. This would be a just-one-hit-updating and less traffic.

Regarding sugestion 2, maybe the problems you have up there are others, but the suggestion 1 would really contribute to take better advantage of the computing power available.

Thanks,

Eduardo
____________

1 - Provide the BOINC sotware with a more acurate gear to detect wich type of WUs are needed to download.

2 - Make the upload to be done in one shift.

Today we have a 3-hit-uploading: a)we first upload and b)report and c)ask for update to see the updated numbers!

...Whatever is in the feeder will go to both CPUs and GPUs alike, just depending on which of the two is asking for it.

And that seems to be the problem with the current versions of the BOINC client: it's asking for the wrong type and amount of tasks!

1 - Gundolf understood very well and I don't understand why the boinc client must be blind to the type of wu needed and why the boinc seti must be blind to the size of wu adequate to each computer. In fact, I wondered that this could be easy, just making use of the already available statistics.

Diferent computers need different sizes of WUs: slow computers smaller units and faster computers and multi-core computers very big WUs and tha reference shall be that tha SETI must keep some "movement" in client screen, to keep the customer interested and thus making his computer available more time.

How can this be not possible to be done?

2 - Since I'm crushing for SETI for almost 5 years now, it's clear that I know that tha validation of a freshly reported WU will take some time, but in this very moment you can take the oportunity to see your updated credit, because some of the WUs you'd reported earlier might be already validated.
And this is not a concern to me but my suggestion was that that report and credit updating to be made between seti-computer-to-seti-computer without the need of using the external communication link again.

Number 2 was just a suggestion but I believe Number 1 woul avoid a lot of traffic and make all crunchers happier leading to more computers hours available to the project.

Thanks,

Eduardo
____________

I understand, I really do but the Project actually does split WUs with diferent sizes . . .

That condition of keeping some "movement" in the customer screen is a marketing approach, to keep the volunteer interested and thus willing to make his computer available more often, I mean not everybody is a setiaholic like me that update equipment at home just to crunch seti and so the marketing thing is important. Right now I see the difficulties that you explained to me but maybe you can include this thinkings - to see the project from the customer point of view - in considerations for major revisions in the future.

Thanks,

Eduardo
____________