Questions and Answers :
Wish list :
Work unit shortage idea
Message board moderation
Author | Message |
---|---|
Darren Send message Joined: 2 Jul 99 Posts: 259 Credit: 280,503 RAC: 0 |
OK, this is not going to win me any friends I'm sure, but after spending a few days trying to help people get boinc up and running and seeing how many people think they have done something wrong because they can't get any work, I think maybe it might be justified. During times of EXTREME work unit shortage, why not limit the number of downloads by ACCOUNT -- when the critical point is reached, stop serving work to all but the one top ranked host for each account. In my case, I have 7 hosts, and while that certainly won't set any records I still like points just as much as the next guy. But, I would not be the slightest bit upset if Berkeley stopped feeding my 6 least productive hosts - as long as the same thing was being done to everyone else. I would simply turn them off myself, but all that would accomplish would be that the few work units they are getting would be sucked up by some IT guy running 1000 hosts that aren't even his (at least one of which, at any given moment in time, will likely be trying to get work). If Berkeley stopped feeding me with a guarantee that it would help out some of these poor little 1 computer guys/gals just trying to get one single work unit to do - so be it, I certainly wouldn't complain about it. Now, call me a bleeding heart liberal if you must (no doubt I've been called worse), but it kind of pisses me off to see people who have gotten thousands of work units (and have hundreds still pending), while some little guy trying his damnedest to help the cause the best that he can is just getting stomped all over and can't even get one. In the absence of some limiting feature like my suggestion above, there at least needs to be one redundant work unit that everybody starts every host with. It could give minimal (or even 0) credit, but the first time you connect a new host, that is the work unit you get. That would serve the purpose of giving the people who are interested a way to see how their computer really stacks up with others, as they could check in their account and see what other computers really did with the exact same work unit. It would also - and more importantly - give EVERYONE at least one work unit at the onset, then they will at least know that their system does, in fact, work. |
Shaktai Send message Joined: 16 Jun 99 Posts: 211 Credit: 259,752 RAC: 0 |
Darren, Not a bad idea, but I think that instead of patching the system to fix a temporary problem, the project managers have decided to utilize their limited resources to fix the problem, by bringing more resources to bear on it. Just one of those decisions that has to be made when you have finite computer and human resources. |
Heffed Send message Joined: 19 Mar 02 Posts: 1856 Credit: 40,736 RAC: 0 |
|
John McLeod VII Send message Joined: 15 Jul 99 Posts: 24806 Credit: 790,712 RAC: 0 |
The way that people are supposed to use to get around outages and still do useful work is to join other projects. There are currently two that are public with more to follow. Protein folding prediction at http://predictor.scripps.edu/ and the BOINC beta test (ongoing at least until S@H1 is killed at http://setiboinc.ssl.berkeley.edu/ap/. |
Heffed Send message Joined: 19 Mar 02 Posts: 1856 Credit: 40,736 RAC: 0 |
> The way that people are supposed to use to get around outages and still do > useful work is to join other projects. There are currently two that are > public with more to follow. Protein folding prediction at > http://predictor.scripps.edu/ and the BOINC beta test (ongoing at least until > S@H1 is killed at http://setiboinc.ssl.berkeley.edu/ap/. I'm trying to attach to predictor and cannot. I get this: http://predictor.scripps.edu/ - 2004-06-26 00:38:06 - Sending request to scheduler: http://predictor.scripps.edu/predictor_cgi/cgi http://predictor.scripps.edu/ - 2004-06-26 00:38:09 - Scheduler RPC to http://predictor.scripps.edu/predictor_cgi/cgi succeeded http://predictor.scripps.edu/ - 2004-06-26 00:38:09 - Message from server: Project is temporarily shut down for maintenance http://predictor.scripps.edu/ - 2004-06-26 00:38:18 - Resetting project http://predictor.scripps.edu/ - 2004-06-26 00:38:18 - Detaching from project I tried re-attaching to beta, and get the same results. (betas website says project is down for maintenance) Anybody know why beta being down wouldn't allow me to access predictor either? (Predictor website is up) I'm tempted to detach from S@H and see if it lets me attach, but I still have two WUs, so I'll wait. Edit: Nevermind. It works now. |
B-SJARMed Send message Joined: 13 Dec 99 Posts: 4 Credit: 1,278,002 RAC: 0 |
Darren, I like your idea of a kind of "reference" packet that has to be send to every computer in the project. This reference packet can serve two purposes: First each computer has at least one packet to process. Secondly from the reference packet is exactly known how many floating point calculations are needed to complete the packet, so the calculation of the credits and the benchmarking of each hostid can be verified and maybe corrected. For load balancing, it would be beter if the number of packets is low, that requests for more work are checked against number of packets pending for that host. If there is a shortage, queues should be emptied first (so computers with lots of packets queued get no work (or just one WU)) This prevents some computers with 20+ packets queued while other computers starve. |
n2vjb Send message Joined: 27 Jul 99 Posts: 4 Credit: 43,853,019 RAC: 0 |
Now that S@H1 is effectively shutdown (no packet/results/news/???) since 07/16/2004, I have converted all of my windows boxes to BOINC. Now I barely get any WUs to do and this is NO better then S@H1 currently. Take the macine resources from the old project if it is dead and get this one up to snuff. If I ran my systems at work this way and left everyone waiting I would be flipping burgers if I was lucky. So much for using excess CPU capacity to do usefule work!!! |
n2vjb Send message Joined: 27 Jul 99 Posts: 4 Credit: 43,853,019 RAC: 0 |
Now that S@H1 is effectively shutdown (no packet/results/news/???) since 07/16/2004, I have converted all of my windows boxes to BOINC. Now I barely get any WUs to do and this is NO better then S@H1 currently. Take the macine resources from the old project if it is dead and get this one up to snuff. If I ran my systems at work this way and left everyone waiting I would be flipping burgers if I was lucky. So much for using excess CPU capacity to do useful work!!! |
John McLeod VII Send message Joined: 15 Jul 99 Posts: 24806 Credit: 790,712 RAC: 0 |
> Now that S@H1 is effectively shutdown (no packet/results/news/???) since > 07/16/2004, I have converted all of my windows boxes to BOINC. Now I barely > get any WUs to do and this is NO better then S@H1 currently. Take the macine > resources from the old project if it is dead and get this one up to snuff. If > I ran my systems at work this way and left everyone waiting I would be > flipping burgers if I was lucky. So much for using excess CPU capacity to do > useful work!!! > S@H ran the same WUs out to the crunchers dozens of times to keep everything working correctly. Only 3 are needed for verification. I would hardly call this useful work all of the time. It is still early in the project, and problems are being fixed. However, when there is not data to split, there will be no WUs from S@H. One of the points of BOINC is that it is multi-project, join the projects of your choice. Unfortunately, there is only one other project at the moment: http://predictor.scripps.edu/. I have my queue set to .1 to .2 days, I am a member of several projects (only 2 of which are currently giving out work). I have only had 5 or 6 hours total in the last month where there was no work from anywhere. |
©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.