Server Not Working Correctly
Server Not Working Correctly |
|
| log in |
Questions and Answers : Web site : Server Not Working Correctly
| Author | Message |
|---|---|
|
Here are two WUs that were marked too late to validate and the actual due dates as shown in a copy of client_state.xml: | |
ID: 1134747 ·  | |
|
In both cases, a quorum was already met and a canonical result was already chosen before you returned your work, making your work invalid even if it was before the deadline you were given. | |
| ID: 1134790 · | |
|
| |
| ID: 1134887 · | |
In a perfect world, it's not supposed to happen, and this is rarity to be certain. But once a canonical result has been chosen, all other copies sent out will be "late" and not receive credit for their work. This has always been the case for many years now. This is the reason why server-side deletes was instituted into the BOINC server code, but the option is very stressful on servers, and SETI's servers simply cannot handle the extra load so it was disabled. No bug here. This is the design of BOINC for a while now. | |
| ID: 1134890 · | |
|
| |
| ID: 1134896 · | |
|
Because there is no code that dictates that all tasks must be returned before a canonical result is chosen and credit is granted. | |
| ID: 1134899 · | |
http://setiathome.berkeley.edu/workunit.php?wuid=741571872 In this specific case, we can see that the first two copies were sent out at the same time (May 11th, 2011), with the first returned result on the 12th. The second copy came in on the 18th. On that same date of the 18th, a third copy was generated, suggesting that the first two results did not match closely enough and so a "tie breaker" was needed. This third workunit had a deadline of July 6th, which the third computer did not finish or could not upload in time before the deadline. So a fourth workunit was sent out on the deadline of July 6th at 0:57 UTC, which was sent to BlackLuke's computer. Then exactly at 1:27 UTC (exactly one half hour after the fourth workunit was sent) the third computer was finally able to upload it's result, thereby concluding the "tie breaker" and granting credit to the original three machines. BlackLuke's workunit may have been returned before his deadline, but it was already irrelevant because a quorum had been met, a canonical result chosen, and credit granted. | |
| ID: 1134902 · | |
1314149027 8/24/2011 1:23:47 30ap11ad.29805.4975.12.10.253.vlar_0 778944033 In the second example here, a workunit was sent out to BlackLuke's computer and a quorum partner on July 8th, 2011. The quorum partner returned his a day later on July 9th, 2011. BlackLuke actually missed this deadline on July 31st, 2011, so a third copy was sent out. The third computer returned their copy on August 1st at 5:07 UTC, matching closely with the first result and completing the quorum (canonical result chosen and credit granted). BlackLuke's computer didn't return his copy until August 1st, 2011 at 8:34 UTC, which was too late, therefore he didn't receive credit. | |
| ID: 1134909 · | |
|
| |
| ID: 1135039 · | |
|
Well I hope David Anderson at least posts here to let us know what the right answer is. As it is, I stand by my findings. | |
| ID: 1135050 · | |
|
| |
| ID: 1135078 · | |
|
Why should it not happen? If the first two results didn't match and a third one is required, then what does it matter if there's four out there so long as the third one meets the quorum? | |
| ID: 1135151 · | |
|
>No bug here. This is the design of BOINC for a while now. | |
| ID: 1135217 · | |
|
As I see it, you have 5 tasks too late to validate. All with a due date of 31 Jul 2011 | 21:55:44 UTC. | |
| ID: 1135275 · | |
>No bug here. This is the design of BOINC for a while now. There wasn't much to your post, how could I not read it? I even investigated each case enough to find out what happened, yet somehow I didn't read it. The actual due dates for the WUs shown was 8/23/11 and 8/24/11; I know this from a backup copy of client_state.xml my system made. Something changed the due dates to 8/1/11, the system sent out a new WU to another user shortly thereafter, and that user returned his result before mine. All I can tell you is what I see. If you have proof of the "real" deadlines, then you should have provided that in your post. As it is, the results only stay visible for 24 hours, so there's a short window of opportunity to see what happened. If the deadlines somehow changed, this would be the first known instance of the deadlines changing. It's more likely that you read the deadlines wrong. Why our hard-nosed, sometimes less than user-centered, masters declared my result invalid while the WU was still in the DB is another question. Why not better late than never? On a recent interview of a writer/producer of a hit TV series ("Everybody Loves Raymond?) on Public Radio, the interviewee said he did not start making any money until he consciously decided to concentrate on being good and being kind. I ask your prayers for more avaricious and kindly masters. So BilBg posts in here that lead Project Administrator David Anderson seems to agree with you, and you call him "hard-nosed, less than user-centered, "masters""? Sounds like you're being quite harsh and over-dramatic. | |
| ID: 1135305 · | |
|
| |
| ID: 1135343 · | |
"I've actually seen this happen before ..." - I don't say it does not happen, I say it should not happen And I say it's fair to not reward credit for a workunit that isn't returned on time or misses the quorum. On the other hand, SETI@Home has been known to give out credits in situations like this when it's their servers and connection that causes the uploading issues. I don't have a problem with that. "... causing the newly sent out workunit to be irrelevant" is true considering science. What deal? A client asks for work, the server hands it out with a deadline. The only reason why the deadline even exists is out of respect for the quorum partner. It's not like the ET signal is going to be suddenly gone if it's not returned on time. BOINC is centered around the fact that work is being sent out to computers of unknown reliability or loyalty. People quit all the time without returning their work. The whole premise of credits is to pay for valid work, which must be returned on time. And it reduces "Max tasks per day". No it doesn't. Only invalid or erred tasks reduce the "Max tasks per day". Missed deadlines do not. The best what the server can do is ask the client to cancel the already made "deal" - send the abort request if the task is not already started at the client. ...and that is built into BOINC, but SETI's servers cannot handle the extra cross-checking. If the client aborts the task the workunit is free to become "case closed". Yes, that's how it works. It would seem it's unfair to the server that some people join and never finish a workunit without at least first telling the serer they aren't going to finish what they've downloaded. (If somebody makes a deal with you saying: "Do this work for me and I will pay you" But if it's made clear to me that I will only get paid for valid work, and I don't turn it in on time, I don't get credit. My girlfriend is going to college, and that's the way her professors are. Her niece is going to grade school, and that's the way her teachers are. Kids don't get credit toward their grade if they return their work late. I'm afraid your analogy doesn't work here. You don't care (and don't even know) that the work was given to you only because another person failed to complete the same work in-time. Actually, you do. If you spend the time to check all your tasks to see if they got credit, you have the time to check to see why you got the task in the first place. All you have to do is click on each task to see what other computers they're assigned to. If you don't care, well then you shouldn't care enough to demand credits for work returned late. What will be your verdict in this case? Well, I don't get to play judge. Only David or Eric or one of the other Project Admins do. But if I did, I would probably manually intervene and grant credit only because the servers have been dropping connections, making it nearly impossible to return work on time. But if the servers weren't dropping connections, then I would not grant credit for late work. | |
| ID: 1135345 · | |
|
| |
| ID: 1135362 · | |
|
John McLeod VII Volunteer developer Volunteer tester  Send message Joined: 15 Jul 99 Posts: 22343 Credit: 440,201 RAC: 100  | |
|
It is not fair to not give credit if a task is reported by its deadline - even if the quorum has already been met. You were asked to do the task, and you did the task and returned it by the time you were supposed to return the task. | |
| ID: 1135365 · | |
Sorry - most of my writing is misunderstood (judging by your responses) Probably not your fault at all. In fact, many people seem to read anger or an acerbic tone to my posts that are not there - and I'm a native English speaker! It's hard to tell based on the fact that most people can't read tone or inflection in words. I'll usually tell people when they're making me angry. Otherwise, if you could hear me face to face, I'm probably just speaking matter-of-factly instead of emotionally (with anger). | |
| ID: 1135371 · | |
Questions and Answers : Web site : Server Not Working Correctly
| Copyright © 2013 University of California |
- 
