BOINC Wish List

Questions and Answers : Wish list : BOINC Wish List
Message board moderation

To post messages, you must log in.

Previous · 1 · 2 · 3 · 4 · 5 · Next

AuthorMessage
Profile X-Files 27
Avatar

Send message
Joined: 17 May 99
Posts: 104
Credit: 111,191,433
RAC: 0
Canada
Message 944484 - Posted: 1 Nov 2009, 20:21:03 UTC

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.
ID: 944484 · Report as offensive
Aurora Borealis
Volunteer tester
Avatar

Send message
Joined: 14 Jan 01
Posts: 3075
Credit: 5,631,463
RAC: 0
Canada
Message 944513 - Posted: 1 Nov 2009, 23:46:46 UTC - in response to Message 944484.  

Similar ideas of giving weight to project priority have been brought up to the Boinc developers in the past, but I expect that they have been placed very low on things to consider doing. It would break (override) the current resource share and LTD system which they don't seem to be too eager to contemplate.

The current priority is to further clean up the operational use of GPU (Nvidia and ATI) and preparing for OpenCL which looks to become the standard for GPU processing. How to handle resource share and scheduling for GPU vs CPU vs Multi-threaded apps vs other resource utilization by projects is being looked at. Also a priority is the social networking interface of Boinc. There are probably several other plans which I'm not aware of on the to-do list.

Project prioritization at the manager level is not likely to be looked at anytime soon, at least not for several major version increments. I personally have project resource share set as high as 20,000, as low as 1 and everything in between to achieve some semblance of prioritizing.

Boinc V7.2.42
Win7 i5 3.33G 4GB, GTX470
ID: 944513 · Report as offensive
Profile Jord
Volunteer tester
Avatar

Send message
Joined: 9 Jun 99
Posts: 15184
Credit: 4,362,181
RAC: 3
Netherlands
Message 946980 - Posted: 13 Nov 2009, 18:15:24 UTC

[trac]changeset:19573[/trac] adds the <exclusive_gpu_app> option to a future version of BOINC.
ID: 946980 · Report as offensive
Profile X-Files 27
Avatar

Send message
Joined: 17 May 99
Posts: 104
Credit: 111,191,433
RAC: 0
Canada
Message 968066 - Posted: 4 Feb 2010, 12:26:07 UTC

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.
ID: 968066 · Report as offensive
Alex Filatov

Send message
Joined: 8 Feb 10
Posts: 90
Credit: 148,574
RAC: 0
Russia
Message 969454 - Posted: 9 Feb 2010, 14:55:08 UTC
Last modified: 9 Feb 2010, 15:00:46 UTC

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.
ID: 969454 · Report as offensive
OzzFan Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer tester
Avatar

Send message
Joined: 9 Apr 02
Posts: 15691
Credit: 84,761,841
RAC: 28
United States
Message 969462 - Posted: 9 Feb 2010, 15:13:27 UTC - in response to Message 969454.  

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.


This has been suggested many times by people who are confused with BOINC's scheduling algorithm. It is actually a very bad idea when you take in all perspectives on the issue.

In fact, BOINC should not focus solely on workunits by deadline date alone. We must remember that BOINC must balance resource shares for many different projects, not just one. Even if you don't use multiple projects, the code must be there to support the idea of running multiple projects.

If BOINC were programed to focus on deadlines only (running earlier deadlines before later ones), some projects would not get enough CPU time to complete, and resource shares would be be honored properly, prompting a bunch of "why am I not downloading X project's tasks?".

Take for instance the projects that have about an hour runtime, with deadlines only 2 days away (Superlink@Technion is one of them). Every time a task is downloaded from that project, all other tasks are suspended to make way for this project's short deadlines.

Or the opposite extreme; ClimatePrediction. These workunits can take up to 750 hours or longer to complete, with a deadline about a year away. These tasks almost assuredly would never receive CPU time until it is almost to late.

Take into account that the time-to-completion are only estimates and can be off in either direction, and it's easy to see why BOINC doesn't operate in deadline-only mode.

Instead, BOINC normally operates in "First in, First out" mode. That is, it works on workunits as they are received. If, through BOINC's advanced scheduling algorithm it detects that a workunit is in deadline danger, it will switch from FIFO to "Earliest Deadline First" (EDF, the way you are suggesting) for only those workunits that are in deadline danger. Once the danger is gone, BOINC returns to FIFO scheduling.

This way, all projects get a chance at keeping their resource shares as set by the user, and all workunits have a fair chance of being processed as equally as the resource shares are set up.
ID: 969462 · Report as offensive
Alex Filatov

Send message
Joined: 8 Feb 10
Posts: 90
Credit: 148,574
RAC: 0
Russia
Message 969464 - Posted: 9 Feb 2010, 15:20:07 UTC
Last modified: 9 Feb 2010, 15:24:18 UTC

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?
ID: 969464 · Report as offensive
OzzFan Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer tester
Avatar

Send message
Joined: 9 Apr 02
Posts: 15691
Credit: 84,761,841
RAC: 28
United States
Message 969497 - Posted: 9 Feb 2010, 16:57:52 UTC - in response to Message 969464.  

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?


Not really. Deadlines aren't that important. If a deadline isn't met, then the task will simply be sent out to someone else to crunch. Why should it really matter which one is processed first if they all make it back on time?

Or phrased a different way, if BOINC's natural scheduler already does an excellent job of returning work on time, then why should it matter what order they are processed in? It's only the human component that is concerned about it. The computer doesn't care.
ID: 969497 · Report as offensive
Alex Filatov

Send message
Joined: 8 Feb 10
Posts: 90
Credit: 148,574
RAC: 0
Russia
Message 969554 - Posted: 10 Feb 2010, 10:57:40 UTC
Last modified: 10 Feb 2010, 10:59:00 UTC

I understand and must agree.
ID: 969554 · Report as offensive
Howard's Fire Protection Inspections, LLC.

Send message
Joined: 2 Mar 10
Posts: 4
Credit: 674,225
RAC: 0
United States
Message 975696 - Posted: 4 Mar 2010, 13:07:49 UTC - in response to Message 969554.  

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!
ID: 975696 · Report as offensive
Profile Steven Meyer
Avatar

Send message
Joined: 24 Mar 08
Posts: 2333
Credit: 3,428,296
RAC: 0
United States
Message 975818 - Posted: 5 Mar 2010, 2:03:58 UTC - in response to Message 975696.  

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


For even faster results, use the big red switch on the side of the case. :D

ID: 975818 · Report as offensive
John McLeod VII
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 15 Jul 99
Posts: 24806
Credit: 790,712
RAC: 0
United States
Message 975841 - Posted: 5 Mar 2010, 3:48:51 UTC - in response to Message 975696.  

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!

In this case, the CPU scheduler and work fetch have to have enough smarts to work without intervention, and that is plenty hard enough.


BOINC WIKI
ID: 975841 · Report as offensive
Profile Eduardo Bicudo Dreyfuss

Send message
Joined: 20 Jun 05
Posts: 58
Credit: 1,386,154
RAC: 0
Brazil
Message 981650 - Posted: 20 Mar 2010, 14:34:43 UTC

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
ID: 981650 · Report as offensive
Profile Jord
Volunteer tester
Avatar

Send message
Joined: 9 Jun 99
Posts: 15184
Credit: 4,362,181
RAC: 3
Netherlands
Message 981661 - Posted: 20 Mar 2010, 15:28:06 UTC - in response to Message 981650.  

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

BOINC can already do this, which is why you can get Seti Enhanced and Astropulse downloaded on this project.

Seti Enhanced has all the same work which will go to CPU or GPU, depending on what your BOINC client is asking for, while Astropulse will go to the CPU and not the GPU (as long as you use the stock Seti applications).

So strictly spoken, in the case of Seti Enhanced, there is no 'different type of task'. Whatever is in the feeder will go to both CPUs and GPUs alike, just depending on which of the two is asking for it.

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!

Uploading is simply transferring the resulting data of the task you did from your hard drive to a hard drive on a project server. It's only after this has successfully been done that the task can be reported to the database as being done (crunched and uploaded in one piece).

With "updated numbers" I assume you mean your credit. Since all work that your computer has done has to be validated against another computer, it may take time before you get credit. It's not instantaneously after you uploaded/reported, although it can happen that you get credit a minute after you uploaded and separately reported.

In any case, you'll get those updated numbers at any new request for work.
ID: 981661 · Report as offensive
Profile Gundolf Jahn

Send message
Joined: 19 Sep 00
Posts: 3184
Credit: 446,358
RAC: 0
Germany
Message 981680 - Posted: 20 Mar 2010, 16:19:39 UTC - in response to Message 981661.  

...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! At least that's the impression I get from reading the fora (on different projects). And that might have led Eduardo to make his request, too.

Gruß,
Gundolf
ID: 981680 · Report as offensive
Profile Jord
Volunteer tester
Avatar

Send message
Joined: 9 Jun 99
Posts: 15184
Credit: 4,362,181
RAC: 3
Netherlands
Message 981690 - Posted: 20 Mar 2010, 17:05:48 UTC - in response to Message 981680.  

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!

Nothing we can do about that. No-one except Richard wants to run with work-fetch debug flags, and post that information to the correct email list, so how are the devs going to fix that?
ID: 981690 · Report as offensive
Profile Eduardo Bicudo Dreyfuss

Send message
Joined: 20 Jun 05
Posts: 58
Credit: 1,386,154
RAC: 0
Brazil
Message 982247 - Posted: 21 Mar 2010, 19:34:32 UTC - in response to Message 981690.  

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
ID: 982247 · Report as offensive
John McLeod VII
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 15 Jul 99
Posts: 24806
Credit: 790,712
RAC: 0
United States
Message 982288 - Posted: 21 Mar 2010, 20:35:41 UTC - in response to Message 982247.  

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?

It is nearly impossible. The tasks are pre-split, and you can unly pick up what is available. Having different length tasks makes the splitting and recombination much more difficult. Besides BOINC != SETI, and there are other projects with entirely different work requirements.

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.

But the data still needs to originate at Berkeley from the spliters, and end up there in the master science database. There are only 2 tasks per WU, so there is at most a 50% reduction in download costs, and the upload costs cannot be shared as the validator is, and needs to be there because the volunteer computers are not trusted. The source file for the splitter is too large to share effectively (it fills a 50GB drive), and the volunteer computers still cannot be trusted. Most of the volunteer computers are reliable, but there are a few that are not.


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





BOINC WIKI
ID: 982288 · Report as offensive
Profile Eduardo Bicudo Dreyfuss

Send message
Joined: 20 Jun 05
Posts: 58
Credit: 1,386,154
RAC: 0
Brazil
Message 982364 - Posted: 22 Mar 2010, 1:35:39 UTC - in response to Message 982288.  

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
ID: 982364 · Report as offensive
John McLeod VII
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 15 Jul 99
Posts: 24806
Credit: 790,712
RAC: 0
United States
Message 982511 - Posted: 22 Mar 2010, 22:16:23 UTC - in response to Message 982364.  

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

Each WU contains exactly the same number of seconds of data (with the possible exception of the tag end of the data). They overlap on each end by 15 seconds. SETI tasks contain a fixed banswidth, and AP tasks contain the entire spectrum. The only difference between SETI tasks is the data included in the task, not the size of the task. Similarly for AP.


BOINC WIKI
ID: 982511 · Report as offensive
Previous · 1 · 2 · 3 · 4 · 5 · Next

Questions and Answers : Wish list : BOINC Wish List


 
©2024 University of California
 
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.