Large Stores of Workunits = Longer Time to Grant Credits (Solution: Suggestion for credit system)

Message boards : Number crunching : Large Stores of Workunits = Longer Time to Grant Credits (Solution: Suggestion for credit system)
Message board moderation

To post messages, you must log in.

AuthorMessage
jjhat1

Send message
Joined: 24 Apr 03
Posts: 49
Credit: 61,357
RAC: 0
United States
Message 37754 - Posted: 18 Oct 2004, 1:47:42 UTC

Correct me if I am wrong but is this not true:

1) If people have large amounts of work stored on their computer they will age before they are processed and sent back to the server.
2) The two week deadline must be reached before a lost work unit will be sent again.
3) If someone with a very small store of work units (me) process a unit they will have to wait to get credit until some one has reached that unit in a possibly large pile of units.
4) Everyone complains about the credit system

Now I personally like the credit system but have one suggestion to improve upon the speed in which credits are granted.


My stupid idea… I can wait to be yelled at for it ;)

I believe that the client should report which units are still stored on it. The server then would change their status to “waiting.” If the client connects and reports it has no work units (example of something that would happen after project reset) those work units that were waiting would become “lost.”
They would still be granted credit if by some strange event would be returned but they would be immediately be sent out to another computer for processing. This would allow units to be granted credit under the two week period be allowing people to tell if a work unit is still in line for processing.
My suggestion is almost to enable a trickle for work units, but not to report their status in processing rather if they actually exist and maybe even an ETA till processing or submission time.
This could ease some of the tensions about the credit system.

If people were able to see how long they may have to wait on John Doe to process his work unit maybe they wont go so crazy over everything. The feature of tracking lost work units would also allow credit to be obtained at an accelerated rate. We all have dumped some work units in our time with BOINC and we all know it really hurts to do it. :) If work units were to be tracked it could even help identify those people that are downloading and dumping by putting up a red flag to ban that account from further download or further restrict their work unit downloads until they actually process something.

In summary:
1) I would like to see work units be tracked
2) Their status would be reported each time the client connects
3) If a prior work unit was suddenly not reported to be on the client a flag would go up that the work unit was lost and would be sent out again
4) A possible estimation of ETA for work units especially on computers that have different projects to work on and for computers that store lots and lost of work units.
5) Maybe we could even group computers. Computers with small stores of work process units with other computers that turn work units over fast and the slow turnover computers work with other slow turnover computers. Although this idea is more impractical it would help the credit system and hey it is my thread. ;)

Now that I have just spent all this time typing. Tell me what you think.

Am I an idiot or would this be a good feature to add to BOINC?



<a href="http://www.boincstats.com/stats/boinc_user_graph.php?id=877f93559fda9f7c5a65f974a8763090"><img src="http://www.boincstats.com/stats/banner.php?cpid=877f93559fda9f7c5a65f974a8763090"></a>
ID: 37754 · Report as offensive
Profile Toby
Volunteer tester
Avatar

Send message
Joined: 26 Oct 00
Posts: 1005
Credit: 6,366,949
RAC: 0
United States
Message 37759 - Posted: 18 Oct 2004, 2:06:13 UTC

Definitely some good thoughts. I don't know that ALL of it would work without overloading the servers but it is good to dream anyway :)

Actually some of this will be adressed in the next substantial client upgrade. One new feature of the client currently in alpha (maybe beta by now) is the ability to manually cancel work units. Don't know the details but presumably this would send a message to the server saying "yo! I don't plan on processing this work unit anymore so give it to someone else". I would HOPE they also change the reset/detach features to go through and cancel all the work units automatically. This obviously won't help for people who just keep a long queue and don't care or don't watch their systems close enough to notice if they are going to miss the deadline but it should help a little I think.

Of course the entire issue is complicated by multiple projects. Estimating an ETA based on queue size and benchmarks on the server side could only take one project into account. Now if the client supplies the ETA to the server, it may be a little more accurate.

There is my two cents :)
A member of The Knights Who Say NI!
For rankings, history graphs and more, check out:
My BOINC stats site
ID: 37759 · Report as offensive
jjhat1

Send message
Joined: 24 Apr 03
Posts: 49
Credit: 61,357
RAC: 0
United States
Message 37760 - Posted: 18 Oct 2004, 2:13:31 UTC - in response to Message 37759.  
Last modified: 18 Oct 2004, 2:22:06 UTC

> ETA based on queue size and benchmarks on the server side could only take one
> project into account. Now if the client supplies the ETA to the server, it
> may be a little more accurate.

Sorry I forgot to mention that. I did expect that the client would supply the ETA. It would use the predicted CPU times (which hopefully become more accurate) and an "order of results" to guess at when the work unit may be submitted. Maybe not very specific but when the deadline is two weeks, diffrent for some projects, and a ball park range would be sufficient.


It would add a considerable amount of CPU load and that is a major concern. It would be nice to have the project reset actually report to the server what work units were lost. Also the cancel work unit feature to stop troublesome units would be another feature to add.

Had there been any talk about a dynamic feature to prevent deadline problems in the client? Limiting work downloaded, correcting ridiculous project shares, things like that...


I forgot to ask: Is their any news on the client having work with approaching deadlines take preference over other work? Examples that I can think of would be people with lots of work already stored and then they download a LHC wu or Predictor (if they ever get their servers) wu that has a day or two deadlines. It should be bumped to the head of the line to keep if from going past its deadline because in many cases it would be days or even a week until it would be its turn in line for some computers. By that time it would be useless.
<a href="http://www.boincstats.com/stats/boinc_user_graph.php?id=877f93559fda9f7c5a65f974a8763090"><img src="http://www.boincstats.com/stats/banner.php?cpid=877f93559fda9f7c5a65f974a8763090"></a>
ID: 37760 · Report as offensive
Bart Barenbrug

Send message
Joined: 7 Jul 04
Posts: 52
Credit: 337,401
RAC: 0
Netherlands
Message 37821 - Posted: 18 Oct 2004, 6:08:53 UTC

> If people were able to see how long they may have to wait on John Doe to process
> his work unit maybe they wont go so crazy over everything.

Well, as a first estimate, I can go to my result page, and click on any work-unit. That will give me an overview of who is working on that work unit also. Clicking on the entries in the first column, will show the report deadlines for each of the results. So I can already have a good idea how long it might take that work unit to complete.

I think it will be hard to make the estimate more precise than just using the report deadline: not everybody has their computer processing at a constant rate (laptops, other work being done on the computer etc.), so it would be hard for even the client to come up with a better prediction in the general case.
ID: 37821 · Report as offensive
Allan Taylor

Send message
Joined: 31 Jan 00
Posts: 32
Credit: 270,259
RAC: 0
Canada
Message 37824 - Posted: 18 Oct 2004, 6:40:04 UTC

I would like to see some limits on work unit downloads. Instead of letting us type in any number for days to connect, I would prefer if it was a drop down list with a range of settings. Say something like: 0.1 day, 0.5 day, 1 day, 2 days, ..., 7 days. This way it would be harder for people to download more units then they can process before the deadline (not impossible if they are in to many projects, just harder).


ID: 37824 · Report as offensive
Bob Chr. Laryea
Avatar

Send message
Joined: 1 May 02
Posts: 122
Credit: 83,877
RAC: 0
Denmark
Message 37833 - Posted: 18 Oct 2004, 7:45:37 UTC - in response to Message 37824.  

> I would like to see some limits on work unit downloads. Instead of letting us
> type in any number for days to connect, I would prefer if it was a drop down
> list with a range of settings. Say something like: 0.1 day, 0.5 day, 1 day, 2
> days, ..., 7 days. This way it would be harder for people to download more
> units then they can process before the deadline (not impossible if they are in
> to many projects, just harder).
>
>
>
You have my vote to on this and as far i can remember, it was so once.
Regards
ID: 37833 · Report as offensive
Profile Keck_Komputers
Volunteer tester
Avatar

Send message
Joined: 4 Jul 99
Posts: 1575
Credit: 4,152,111
RAC: 1
United States
Message 37936 - Posted: 18 Oct 2004, 16:11:11 UTC - in response to Message 37824.  

> I would like to see some limits on work unit downloads. Instead of letting us
> type in any number for days to connect, I would prefer if it was a drop down
> list with a range of settings. Say something like: 0.1 day, 0.5 day, 1 day, 2
> days, ..., 7 days. This way it would be harder for people to download more
> units then they can process before the deadline (not impossible if they are in
> to many projects, just harder).
>
This has my vote as well. With the added note that this max should be settable by each project and will propagate to all projects. Since some projects need shorter max queues than others.
BOINC WIKI

BOINCing since 2002/12/8
ID: 37936 · Report as offensive
Profile John Cropper
Avatar

Send message
Joined: 3 May 00
Posts: 444
Credit: 416,933
RAC: 0
United States
Message 37947 - Posted: 18 Oct 2004, 16:45:40 UTC - in response to Message 37754.  

Wouldn't it be simpler to create a session key based on client communications, then link that key to all the work units being held by that client session?

That way, if a client resets, the work units linked to that key will be released to be redistributed sooner rather than later.

Stewie: So, is there any tread left on the tires? Or at this point would it be like throwing a hot dog down a hallway?

Fox Sunday (US) at 9PM ET/PT
ID: 37947 · Report as offensive
Profile THESPEEKER
Avatar

Send message
Joined: 3 Apr 99
Posts: 168
Credit: 48,990
RAC: 0
United Kingdom
Message 37955 - Posted: 18 Oct 2004, 17:31:37 UTC - in response to Message 37759.  

> Actually some of this will be adressed in the next substantial client upgrade.
> One new feature of the client currently in alpha (maybe beta by now) is the
> ability to manually cancel work units. Don't know the details but presumably
> this would send a message to the server saying "yo! I don't plan on
> processing this work unit anymore so give it to someone else". I would HOPE
> they also change the reset/detach features to go through and cancel all the
> work units automatically.

If this was in ver 4.13 or 4.12 it would of helped alot of people to cancel the Wu's that they all got after all the resets that people did from failed uploads
when running ver 4.09 and Wu's 14mr****'s. I have approx 40 Wu's on my account that will not get crunched before the deadline(i appologise to all who will not receive credits for this in advance)as i reset twice because i had 5 failed out of 9 uploads in my first 2 days of joining(7/10/04)and through advise given i reset.

thanks for your post Toby and i hope this is implemented.
ID: 37955 · Report as offensive

Message boards : Number crunching : Large Stores of Workunits = Longer Time to Grant Credits (Solution: Suggestion for credit system)


 
©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.