That is certainly true, but in the cases that I investigated - which started with posts in various degrees of indignation on the message boards - the users were adamant that copying of data directories had *not* taken place.
>________________________________ > From: "McLeod, John" <[email protected]> >To: Eric J Korpela <[email protected]>; Richard Haselgrove ><[email protected]> >Cc: "[email protected]" <[email protected]> >Sent: Friday, 8 August 2014, 18:47 >Subject: RE: [boinc_dev] astropulse robustness / abandonned tasks > > >One technique used to create a new host that is attached to everything that an >old host is attached to is to copy the entire data directory from old to new >and install BOINC on the new host. This would tend to preserve the sequence >number. > >-----Original Message----- >From: boinc_dev [mailto:[email protected]] On Behalf Of Eric >J Korpela >Sent: Friday, August 08, 2014 1:44 PM >To: Richard Haselgrove >Cc: [email protected] >Subject: Re: [boinc_dev] astropulse robustness / abandonned tasks > >The other possibility is the sender doesn't think the prior RPC completed >and didn't update the sequence number (although I haven't looked at the >code to see if this is possible). With a mismatch of one out of 59643 >seems like the server is reaching exactly the wrong conclusion (this is a >new host) rather than the right one (there was a communications problem on >the prior contact). If it were a new host, shouldn't the sequence number >be near 0? > > >On Fri, Aug 8, 2014 at 10:19 AM, Richard Haselgrove < >[email protected]> wrote: > >> In probably the fullest message board description on the last circuit >> round this merry-go-round, >> >> http://setiathome.berkeley.edu/forum_thread.php?id=70946 >> >> we observed a number of occasions where client message logs contained >> lines like >> >> 22.05.2013 13:45:56 | SETI@home | Not sending work - last request too >> recent: 76 sec >> >> at times not unadjacent to the times when abandonments were recorded for >> user tasks. That led us into 'clutching at straws' mode: was another >> computer sending out-of-sequence RPC requests with duplicate credentials? >> (the users swore not). Were entire RPC requests being delayed in a transit >> queue and arriving out of sequence? Unlikely. Was the server receiving the >> RPCs in a timely fashion, but processing them out of order - perhaps >> delaying one because of incomplete packets? >> >> And so on. Most of this was happening before the server move to CoLo, when >> the SETI data line was heavily congested - we thought the problem might >> diminish with the higher-quality internet service at the bottom of the >> hill, and so it seems to have transpired. But doesn't help our friends >> outwith the continental USA. >> >> Incidentally, I reported seeing one 'last request too recent' in my own >> logs, and traced it back to an internet time update changing the computer >> clock. But I didn't suffer any abandoned tasks in that event. >> >> ------------------------------ >> *From:* Eric J Korpela <[email protected]> >> *To:* Richard Haselgrove <[email protected]> >> *Cc:* "[email protected]" <[email protected]> >> *Sent:* Friday, 8 August 2014, 17:47 >> >> *Subject:* Re: [boinc_dev] astropulse robustness / abandonned tasks >> >> His host seems to be losing track of RPC sequence numbers. Loss of cached >> writes on restart? >> >> 2014-08-08 07:13:53.1883 [PID=28339] [HOST#6960982] [USER#8522684] RPC >> seqno 59642 less than expected 59643; creating new host >> 2014-08-08 07:13:53.1896 [PID=28339] [HOST#6960982] [USER#8522684] Found >> similar existing host for this user - assigned. >> 2014-08-08 07:13:53.1932 [PID=28339] [CRITICAL] [HOST#6960982] >> [RESULT#3670788988] [WU#1562416658] changed CPID: marking in-progress >> result 03se08ad.16169.8252.438086664200.12.220_0 as client error! >> 2014-08-08 07:13:53.1932 [PID=28339] Request: [USER#8522684] >> [HOST#6960982] [IP 41.79.224.134] client 7.2.42 >> >> >> >> On Fri, Aug 8, 2014 at 9:17 AM, Richard Haselgrove < >> [email protected]> wrote: >> >> > The same user appears to have suffered another 'abandon' event today: >> > >> > http://setiathome.berkeley.edu/results.php?hostid=6960982&state=6 >> > >> > The reasons mentioned by Eric are all valid, but there appears to be an >> > irreducible core of sporadic events which cannot be ascribed to user >> > malfeasance. In earlier reports like this, many (but not all) of the >> cases >> > appeared to be associated with long-distance and/or poor quality internet >> > connections - again, like this one. >> > >> > ------------------------------ >> > *From:* Eric J Korpela <[email protected]> >> > *To:* "McLeod, John" <[email protected]> >> > *Cc:* "[email protected]" <[email protected]>; Richard >> > Haselgrove <[email protected]> >> > *Sent:* Friday, 8 August 2014, 16:56 >> > >> > *Subject:* Re: [boinc_dev] astropulse robustness / abandonned tasks >> >> > >> > Astropulse does checkpoint quite frequently, and restarts without problem >> > most of the time. "Abandoned" is definitely a server side decision that >> > indicates a client detach or a reset or some sort of confusion as to the >> > identity of a host and whether it was working on those results. (Other >> > possibilities include multiple hosts using a copied or shared BOINC >> > directory, multiple copies of BOINC on one host using the same BOINC >> client >> > directory, deletion or corruption or bad permissions on files in the >> BOINC >> > client directory, any of which could confuse client or server). >> > >> > >> > Which client version and OS are you using? >> > >> > >> > On Fri, Aug 8, 2014 at 5:55 AM, McLeod, John <[email protected]> >> wrote: >> > >> > > BOINC has a checkpointing mechanism built in, but it requires that the >> > > project developers write checkpoint code. Some projects can checkpoint >> > > almost any time, and others can checkpoint only every few minutes, and >> > some >> > > cannot checkpoint at all. SETI can checkpoint frequently (and >> instigated >> > > the mechanism to NOT do every possible checkpoint, but only once every >> X >> > > minutes). CPDN always checkpoints every time it can (typically this is >> > > several minutes). I cannot remember an example of one that cannot >> > > checkpoint at all, but they exist. >> > > >> > > -----Original Message----- >> > > From: boinc_dev [mailto:[email protected]] On Behalf >> Of >> > > Richard Haselgrove >> > > Sent: Friday, August 08, 2014 4:48 AM >> > > To: Luc A. Germain; [email protected] >> > > Subject: Re: [boinc_dev] astropulse robustness / abandonned tasks >> > > >> > > The abandoning of tasks happens when the BOINC server 'thinks' that it >> > has >> > > 'evidence' that the client has detached from the project and then >> > > re-attached again. This has affected a number of users in the past, but >> > has >> > > proved extremely tricky to diagnose and resolve: not least, because >> most >> > of >> > > the evidence resides in the server logs. >> > > >> > > We did investigate one suspected case at Albert during credit testing, >> > but >> > > that turned out to be a genuine 'detach' caused by hard disk failure - >> it >> > > is distinguished from reports like this one because no running tasks >> were >> > > left on the host computer (they were on the drive that failed...) to >> > waste >> > > time and electricity. >> > > >> > > I would certainly welcome it if we could pair up a developer and a >> > project >> > > administrator with access to server logs to investigate this problem >> and >> > > cure it at source. >> > > >> > > The checkpointing question is a matter for the project developers, and >> > > I'll leave it to them to respond via this list. >> > > >> > > >> > > >> > > >________________________________ >> > > > From: Luc A. Germain <[email protected]> >> > > >To: [email protected] >> > > >Sent: Friday, 8 August 2014, 9:41 >> > > >Subject: [boinc_dev] astropulse robustness / abandonned tasks >> > > > >> > > > >> > > >Hi, >> > > >Two things: >> > > >1) A suggestion here for you develloppers ;-) As atropulse tasks take >> > > "some" time to complete they are more prone to power failure as we have >> > in >> > > the third world. When it happens most of the time the task restarts >> > > computing from start (this is even more frustrating when the task >> reaches >> > > near completion). Could it be possible to introduce regular checkpoints >> > by >> > > saving intermediate data, or work files, where the task computing could >> > > restart from, saving so a lot of computing time ? Maybe this could be >> an >> > > option in the user profile as I guess not everyone needs this. >> > > > >> > > >2) Two days ago I sent a message about abandonned tasks. Since, all my >> > > computing goes to the garbage bin as they are not taken into account. >> > Which >> > > procedure should/could I try to solve this problem ? Could >> > > uninstalling/reinstalling the application from my computers be a >> > solution? >> > > Should I wait till the problem solves by itself (and would this not >> take >> > > ages) ? >> > > > >> > > >An answer would be highly appreciated. >> > > > >> > > >Best regards and thanks for your work, >> > > >Luc >> > > >_______________________________________________ >> > > >boinc_dev mailing list >> > > >[email protected] >> > > >http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev >> > > >To unsubscribe, visit the above URL and >> > > >(near bottom of page) enter your email address. > >> > > > >> > > > >> > > > >> > > _______________________________________________ >> > > boinc_dev mailing list >> > > [email protected] >> > > http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev >> > > To unsubscribe, visit the above URL and >> > > (near bottom of page) enter your email address. >> > > _______________________________________________ >> > > boinc_dev mailing list >> > > [email protected] >> > > http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev >> > > To unsubscribe, visit the above URL and >> > > (near bottom of page) enter your email address. >> > > >> > _______________________________________________ >> > boinc_dev mailing list >> > [email protected] >> > http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev >> > To unsubscribe, visit the above URL and >> > (near bottom of page) enter your email address. >> > >> > >> > >> _______________________________________________ >> boinc_dev mailing list >> [email protected] >> http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev >> To unsubscribe, visit the above URL and >> (near bottom of page) enter your email address. >> >> >> >_______________________________________________ >boinc_dev mailing list >[email protected] >http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev >To unsubscribe, visit the above URL and >(near bottom of page) enter your email address. > > _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
