| Author |
Message |
|---|
|
|
|
--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
 |
|
|
|
|
|
> 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] |
|
|
|
|
|
> > 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> |
|
|
|
|
|
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!
|
|
|
|
|
|
> 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.
|
|
|
|
|
|
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* |
|
|
|
|
|
> 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] |
|
|
|
|
|
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™
 |
|
|
|
|
|
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>
 |
|
|
|
|
|
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™
|
|
|
|
|
|
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 ...
|
|
|
|
|
|
> 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?
|
|
|
|
|
|
> (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™
|
|
|
|
|
|
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 ...
|
|
|
|
|
|
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... :/
|
|
|
