Message boards :
Number crunching :
Work Unit 3 claimed with 0 granted
Message board moderation
Author | Message |
---|---|
Send message Joined: 24 Oct 04 Posts: 79 Credit: 257,762 RAC: 0 |
Take a look http://lhcathome.cern.ch/workunit.php?wuid=69598 Does this also happen more than just the 0 cpu time thus adding to the credit problem? I watched this 1 run and showed a cpu time when ready to report,ran normal... a lot don't show cpu time after normal run and runtime rotsaruck lol |
Send message Joined: 18 Sep 04 Posts: 143 Credit: 27,645 RAC: 0 |
If you read the news on the front side and this thread, you would be informed a bit more. ;) Just stick around and keep posting on the forums about units like that and maybe that the people at LHC can find the cure. Jord BOINC FAQ Service |
Send message Joined: 24 Oct 04 Posts: 79 Credit: 257,762 RAC: 0 |
Sorry If I offended you agless due to my ahh lack of being informed but I thought project admin wanted to know about each instance to pin down the prob ... ahh my understanding....Do I need to research thread and give you the link? Thank-you JR |
Send message Joined: 18 Sep 04 Posts: 143 Credit: 27,645 RAC: 0 |
You didn't offend me one bit. :) I should say sorry if my post above came over a tad too harsh. Just keep on posting those units that go to zero without any given clue. :D (See all the smileys? ;)) Jord BOINC FAQ Service |
Send message Joined: 24 Oct 04 Posts: 79 Credit: 257,762 RAC: 0 |
Hehe Ageless been on net for bout 10 years .....Always hate the lack of facial and body language on postings and live chat... seems tooo easy to misinterpret anothers written conveyance... also hate the controversy and posts about quitting projects due to fiduciary responsibility and the like...hell... if your were getting all credits at LHC you wouldn't be getting credit in another project anyway .... your doing science in a BETA project so quit whinning... hehe Yes Ageless I'd like to see the problem solved and until it is you may see more of these posts about workunits I can verify at this end. :D |
Send message Joined: 18 Sep 04 Posts: 143 Credit: 27,645 RAC: 0 |
That's the spirit! Mind, I am in no way 'attached' to LHC other than that I am crunching zero credit units, but if only we give the project admins a clue on where it went wrong, they may be able to get things working again. :) Jord BOINC FAQ Service |
Send message Joined: 2 Sep 04 Posts: 545 Credit: 148,912 RAC: 0 |
> Take a look http://lhcathome.cern.ch/workunit.php?wuid=69598 Does this also > happen more than just the 0 cpu time thus adding to the credit problem? I > watched this 1 run and showed a cpu time when ready to report,ran normal... a > lot don't show cpu time after normal run and runtime rotsaruck lol Well, just another side thought, for the developers to consider. maybe a small modification to the kill top and bottom average the middle ... I made a suggestion to the Developers mailing list and maybe something will come of that ... in this case, one of the quorum members did have a non-zero claim and that should have been used as a basis for the assignment of credit ... Not a comple cure, but possibly a way to avoid ALL of the consequences. A retro scan of the database if they wanted to make a query to do that could "repair" the "damage" for those cases where this situation obtains, though I don't much care one way or another ... |
Send message Joined: 24 Oct 04 Posts: 79 Credit: 257,762 RAC: 0 |
Basically I think I agree with you Paul. The project ought to go from a 2 quorum to a 3 quorum. Not only does it properly credit more results ,I believe it also helps the scientific validation. As in Einstein 3 makes the quorum and seems to work rather well. As long as a deadline that LHC gives you and as short a workunit as is typical,and as problematic as it seems the project is in supplying 5000 hosts with work this makes sense. On a side note it seems funny to me that these "family" projects ie:Boinc don't communicate better between each other as what works and what doesn't. I guess thats your burden Paul. lol |
Send message Joined: 2 Sep 04 Posts: 545 Credit: 148,912 RAC: 0 |
> Basically I think I agree with you Paul. The project ought to go from a 2 > quorum to a 3 quorum. Not only does it properly credit more results ,I believe > it also helps the scientific validation. As in Einstein 3 makes the quorum and > seems to work rather well. As long as a deadline that LHC gives you and as > short a workunit as is typical,and as problematic as it seems the project is > in supplying 5000 hosts with work this makes sense. On a side note it seems > funny to me that these "family" projects ie:Boinc don't communicate better > between each other as what works and what doesn't. I guess thats your burden > Paul. lol Well, i have tried to point out that we are a community in fact if not in design. WOrking within a project I can see how you are swamped with your own work that it is hard to see the forrest ... But, DEC was, in part, so successful because of the group called Decus. They sold more VAX computers than DEC's sales force. They were users and passionate about the reliability and capability of the machines themselves. Just taking my limited exposure to computers as an example I have not seen a machine that was as reliable, and OS so stable just about anywhere else. In the PC world the only OS I have seen that *I* could not kill on a regular basis was OS/2 Warp 4, SP 4 ... (up to SP3 I could still do it, and I still have my install disks :) )... Heck, I can even toast Apples's Panther 10.3.8 on occasion. I am not sure they need to increase the quorum size, or if that would make much difference in the long run. I put in a proposal to the Developer's Mailing list to put in a boundary condition test to avoid the situation where we have "valid" results but zero credit when one of the quorum members did calculate a claim. Obviously, this will not handle the situation where all quorum members have a 0 claim when there all are valid results. But, even without the LHC@Home's specific case, this is a possible boundary condition that was not considered and should have been (Paul's Paranoid Programming at Work). |
Send message Joined: 2 Sep 04 Posts: 352 Credit: 1,393,150 RAC: 0 |
This is the type of WU that frustrates me the most, just because 1 person turned in 0 Time neither 1 of us got any Credit even though my Result was Valid & I turned in the Correct Tiome on it. Then to top it all off 3 more people are going to crunch this WU & more than likely not get any Credit either ... |
Send message Joined: 1 Sep 04 Posts: 139 Credit: 2,579 RAC: 0 |
Yes, I agree with your recommendation to go back to a 3 quorum. Will try and get this done for the next lot of work units submitted. Ben Segal / LHC@home > Basically I think I agree with you Paul. The project ought to go from a 2 > quorum to a 3 quorum. Not only does it properly credit more results ,I believe > it also helps the scientific validation. As in Einstein 3 makes the quorum and > seems to work rather well. As long as a deadline that LHC gives you and as > short a workunit as is typical,and as problematic as it seems the project is > in supplying 5000 hosts with work this makes sense. On a side note it seems > funny to me that these "family" projects ie:Boinc don't communicate better > between each other as what works and what doesn't. I guess thats your burden > Paul. lol > |
Send message Joined: 2 Sep 04 Posts: 545 Credit: 148,912 RAC: 0 |
> Yes, I agree with your recommendation to go back to a 3 quorum. Will try and > get this done for the next lot of work units submitted. > > Ben Segal / LHC@home Ben, I also suggested a modification to the code that would not require a change in your quorum rules, but, in any case: 1) quorum of 2 and the bottom is zero, granted is zero. 2) Quorum is "n" (with N>=3), and you have only one at zero, the granted is non-zero (bottom striped rule). 3) Quorum is "n" (with N>=3) and only one is non-zero, granted is zero (top striped rule) 4) Quorum is "n" (with N>=4) and there are more than one zero and more than one non-zero values => possible problem if not all zero values are not stripped before averaging |
©2024 CERN