Message boards :
Number crunching :
Detach and re-attaching from project
Message board moderation
Author | Message |
---|---|
UBT - Timbo Send message Joined: 3 Apr 99 Posts: 157 Credit: 10,720,947 RAC: 362 |
--quote:-- July 8, 2004 We have moved the scheduling server to another machine in order to free up CPU and memory for the DB server. Active clients will fail 10 times to connect to the old scheduling server and then will self correct by contacting the master URL. To force the correction right away, simply detach and then (re)attach the project. --unquote-- What the wonderful people of Berkeley DON'T tell you is: 1) By performing the above, it deletes any work you are doing (or have done) for the current WU. 2) It also deletes any cached WU's that were downloaded and waiting - hence any other crunchers expecting to get credit when you return these WU's will have to wait longer, as the cached WU's are deleted from your local HDD. 3) When you re-attach you have a completely new ID and hence a new "history" has to be built up. 4) Maybe there's some other stuff as well - will wait and see what other screw-up's come from Berkeley. MORAL: DON'T detach and then re-attach - it ain't worth it. Timbo |
Heffed Send message Joined: 19 Mar 02 Posts: 1856 Credit: 40,736 RAC: 0 |
> 3) When you re-attach you have a completely new ID and hence a new "history" > has to be built up. And this is relevant because?... <a> [/url] |
JAF Send message Joined: 9 Aug 00 Posts: 289 Credit: 168,721 RAC: 0 |
> > 3) When you re-attach you have a completely new ID and hence a new > "history" > > has to be built up. > > And this is relevant because?... > > <a> |
EclipseHA Send message Joined: 28 Jul 99 Posts: 1018 Credit: 530,719 RAC: 0 |
I'll admit, when I first saw the news on the website, I laughed... Only because it showed that UCB was as lost as I'd feared. (I knew the results of detatch/attach, as I thought UCB did!) They told all users that the "simple/fast" fix was to zap all WU's on your machine, be they RTR, in progress, or just queued and waiting their turn. As a result, there's now a bunch of work which was done by users and was thrown away. And there will be a slew of WU's which will not get 3 valid results in the next couple of weeks, and will need to timeout and be reissued! |
Darren Send message Joined: 2 Jul 99 Posts: 259 Credit: 280,503 RAC: 0 |
> And there will be a slew of WU's which will not get 3 valid results in > the next couple of weeks, and will need to timeout and be reissued! Not to mention the many thousands of caches that finally got filled, only to be emptied back out in such a rude manner ... and now they're all going to be needing to be filled again. Looks like we're probably going to be in for another marathon shortage of available work, as all the work units they've spent the last few days creating won't be ready to go back out now for 2 weeks. |
Wayne Send message Joined: 19 Oct 02 Posts: 13 Credit: 88,859 RAC: 0 |
I dont know why they told us to detach and reattach.. i just 'Updated' the project 10 times in a row and it attached to the correct scheduler... *shrugs* |
Heffed Send message Joined: 19 Mar 02 Posts: 1856 Credit: 40,736 RAC: 0 |
> If you think it's funny that a lot of us followed the instructions in the > message and lost work units, I hope you feel good. Errmmmm... Why would I think that's funny? <a> [/url] |
Jord Send message Joined: 9 Jun 99 Posts: 15184 Credit: 4,362,181 RAC: 3 |
So did I... well, 12 times. But I can't say I find a clear path in the way the scheduler failing is telling BOINC when to retry. My 12 manual tries gave these results: SETI@home - 2004-07-09 02:59:54 - Deferring communication with project for 1 minutes and 0 seconds SETI@home - 2004-07-09 03:00:02 - Deferring communication with project for 1 minutes and 0 seconds SETI@home - 2004-07-09 03:00:10 - Deferring communication with project for 1 minutes and 0 seconds SETI@home - 2004-07-09 03:00:17 - Deferring communication with project for 1 minutes and 0 seconds SETI@home - 2004-07-09 03:00:24 - Deferring communication with project for 2 minutes and 10 seconds SETI@home - 2004-07-09 03:00:36 - Deferring communication with project for 5 minutes and 57 seconds SETI@home - 2004-07-09 03:00:43 - Deferring communication with project for 16 minutes and 29 seconds SETI@home - 2004-07-09 03:00:50 - Deferring communication with project for 46 minutes and 52 seconds SETI@home - 2004-07-09 03:01:00 - Deferring communication with project for 27 minutes and 59 seconds SETI@home - 2004-07-09 03:01:09 - Deferring communication with project for 1 hours, 21 minutes, and 28 seconds SETI@home - 2004-07-09 03:01:18 - Deferring communication with project for 1 minutes and 0 seconds SETI@home - 2004-07-09 03:01:36 - Scheduler RPC to http://setiboincdata.ssl.berkeley.edu/sah_cgi/cgi succeeded I give up. :D ---------------------- Jordâ„¢ |
Chip Long Send message Joined: 2 Aug 00 Posts: 445 Credit: 503,693 RAC: 0 |
Jord... > SETI@home - 2004-07-09 03:01:36 - Scheduler RPC to > http://setiboincdata.ssl.berkeley.edu/sah_cgi/cgi succeeded Actually on the 12th try... the request 'succeeded'... the next time that client tries to connect... it should succeed and the update / upload / low water mark download... should succeed as well... Regards <FONT FACE='ARIAL'>chip w3range.net</FONT> <BR> |
Jord Send message Joined: 9 Jun 99 Posts: 15184 Credit: 4,362,181 RAC: 3 |
Okay, but I still had to press the Update manually 12 times. Is what I meant. And all the rest, pffft, I know that already. Mostly... sometimes. ;) It'll run its course. It's downloading more PAH units at the moment. ---------------------- Jordâ„¢ |
STE\/E Send message Joined: 29 Mar 03 Posts: 1137 Credit: 5,334,063 RAC: 0 |
I'll admit, when I first saw the news on the website, I laughed... Only because it showed that UCB was as lost as I'd feared. (I knew the results of detatch/attach, as I thought UCB did!) =========== Well maybe UCB thought that since they had everything else screwed up they might as well screw the crunchers as well ... Not Nice at all ... |
EclipseHA Send message Joined: 28 Jul 99 Posts: 1018 Credit: 530,719 RAC: 0 |
> Well maybe UCB thought that since they had everything else screwed up they > might as well screw the crunchers as well ... Not Nice at all ... Heck, they started screwing the crunchers on 6/22! HOWEVER! It does seem the validator is now running! I got 3 times the granted credit I had this morning (and had for the last week) Next it will be "UBC here - the benchmarks are bogus, so we've reset everyone's claimed credit to 0. Please download the new BOINC, as we'll accept no WU's processed by the old one" My Celeron 2.2g (rhat linux) queues 6-7 times the work as my P4 2.4g (w2k) does using the same preferences! The benchmark is bogus (the celeron benchmarks much higer than the P4, and we all know that's wrong!), therefore "claimed credit" is bogus, therefore "granted credit" is bogus.. Could this be the REAL reason we can't view our results? |
Jord Send message Joined: 9 Jun 99 Posts: 15184 Credit: 4,362,181 RAC: 3 |
> (the celeron benchmarks much higer than the P4, and we all know that's wrong!) Might be time you said "Aye" in http://setiweb.ssl.berkeley.edu/sah/forum_thread.php?id=1017 ;) ---------------------- Jordâ„¢ |
JAF Send message Joined: 9 Aug 00 Posts: 289 Credit: 168,721 RAC: 0 |
Sorry Heffed. I was one of those who saw the message and detached and (re)attahced, and lost 20 hurs of work and all the "ready for work" units on my computer. Then I saw the message that I would also have a new ID for my computer, I was upset. Luckily I could merge the old reported credits to the new ID. Anyway, seeing your reply: > > 3) When you re-attach you have a completely new ID and hence a new > "history" > > has to be built up. > > And this is relevant because?... That bothered me because I knew you knew that that person could merge their "history" with their new ID and couldn't understand why you didn't just say that. I should have more patience ... |
STE\/E Send message Joined: 29 Mar 03 Posts: 1137 Credit: 5,334,063 RAC: 0 |
My Celeron 2.2g (rhat linux) queues 6-7 times the work as my P4 2.4g (w2k) does using the same preferences! The benchmark is bogus (the celeron benchmarks much higer than the P4, and we all know that's wrong!), therefore "claimed credit" is bogus, therefore "granted credit" is bogus.. Could this be the REAL reason we can't view our results? ========== Well I think if that happened they might as well turn out the lights and close the door behind them on the way out because they might be the only ones left with any interest in their little Den Of Inequity. I've lived through their Trials and Trivial's with Beta & When they first went Live before they reset the Credits and now with Seti Live, I think I would wash my hands of it if we have to start all over again... :/ |
©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.