A week or two ago, my i7 computer aborted 99 E@H units all on its own. I didn't do it. I was very surprised to check my account one morning and find that I had aborted a bunch of work. I could only guess that it didn't think it could do them by deadline or even that the deadline had passed already. (The same day, I also had one unit marked invalid because it was returned too late.)
I did have a look at your host when you posted this at Seti, Basically Boinc aborted all that work because the deadline had passed (two weeks), and because Einstein is running older server software it can't tell the difference beteeen Boinc aborting the work and you aborting the work.
Actually, his older BOINC client v6.10.60 is sending back the old-style "Exit status -233", which even the older web server code here ought to have rendered using
I'm looking for info about a major outage at Seti)
Posted in the front page of SETI:
Unscheduled Power Outage
Power to the north east side of the Berkeley campus and the Space Science Lab was interruped this morning at about 16:30 UTC until about 17:30. The cause of the outage has not yet been determined. We're working to get our databased back in working order. Current estimate is that we'll be back online on Tuesday, Dec 6. 30 Nov 2012 | 4:42:45 UTC
So expect a looong stay here... so is better to free some cores in you CPU to help the GPU E@H WU running faster on this days...
Yes, I've seen that. I was hoping someone would have been in touch with Eric or somebody and know more. Like why the estimate is Tuesday instead of yesterday afternoon.
David
Miserable old git
Patiently waiting for the asteroid with my name on it.
A week or two ago, my i7 computer aborted 99 E@H units all on its own. I didn't do it. I was very surprised to check my account one morning and find that I had aborted a bunch of work. I could only guess that it didn't think it could do them by deadline or even that the deadline had passed already. (The same day, I also had one unit marked invalid because it was returned too late.)
I did have a look at your host when you posted this at Seti, Basically Boinc aborted all that work because the deadline had passed (two weeks),
That's what I pretty much figured, but why did it get so much in the first place?
Quote:
Quote:
and because Einstein is running older server software it can't tell the difference beteeen Boinc aborting the work and you aborting the work.
Claggy
So back to the point I was making in this particular thread, that may be what happened to the anonymous user the OP is referring to.
Quote:
Actually, his older BOINC client v6.10.60 is sending back the old-style "Exit status -233", which even the older web server code here ought to have rendered using
#define ERR_UNSTARTED_LATE -233
Would it really behoove me to upgrade my Boinc clients?
David
Miserable old git
Patiently waiting for the asteroid with my name on it.
That's what I pretty much figured, but why did it get so much in the first place?
The most probable cause was:
When you switch form SETI to E@H your caches probabily are set for normal SETI big number of days and your resource share must be set to 100 (the E@H defoult).
Then what the scheduler does? It´s job and try to fill the caches to their target number of days, because E@H allways have a large number of WU avaiable to DL, they DL faster than SETI WU. So that the main reason what you get so much on the begining. As the time pass the scheduler start to balance that on what you set on the resource share
You could avoid that with a combination of small caches and/or changes in the resource share number.
After BOINC 7.0.28 was available, I installed it on ,my 3 hosts.
Each running multiple projects, CPU only, CPU+GPU and GPU 'only*'.
*(CPU is always needed).
Unfortunatly my health is very poor and haven't been active on
whatever forum, since a month orso.
BOINC is managing quite well.
I understand Denis Puhar's reaction on the aborted work, but as was pointed
out clear, aborting is 'better',compaired to 'timing out', less 'waiting-time'.
And you're 'daily-quota', will suffer from such an action. Not much
serious harm done here, IMHO.
B.t.w. Einstein is doing very well in Computing Power, as I read.
I'm also amazed by the work done by 16 CPU (cores) and 4 (2x AMD/ATI HD5870
GPU's and a GTX480 & 470, with a 25% Recource Share
That's what I pretty much figured, but why did it get so much in the first place?
The most probable cause was:
When you switch form SETI to E@H your caches probabily are set for normal SETI big number of days and your resource share must be set to 100 (the E@H defoult).
Then what the scheduler does? It´s job and try to fill the caches to their target number of days, because E@H allways have a large number of WU avaiable to DL, they DL faster than SETI WU. So that the main reason what you get so much on the begining. As the time pass the scheduler start to balance that on what you set on the resource share
You could avoid that with a combination of small caches and/or changes in the resource share number.
Actually, my resource shares are 110 Seti, 30 Einstein (and 60 Orbit, but it never has any work and is suspended on that machine).
David
Miserable old git
Patiently waiting for the asteroid with my name on it.
Actually, my resource shares are 110 Seti, 30 Einstein (and 60 Orbit, but it never has any work and is suspended on that machine).
Any number diferent from 0 (zero) will make the cache fill to the maximum, it allways try to keep your host feeded, thats it´s jobs. The problem is with the with the lack of SETI WU.
Actually, my resource shares are 110 Seti, 30 Einstein (and 60 Orbit, but it never has any work and is suspended on that machine).
Any number diferent from 0 (zero) will make the cache fill to the maximum, it allways try to keep your host feeded, thats it´s jobs. The problem is with the with the lack of SETI WU.
Well I use a 3 day and additionel 2 day cache works OK, especially when you're
doing both Einstein and SETI, otherwise you'll be flooded with Einstein work ;-)
Einstein also uses quite a lot of storage, compaired to SETI.
Einstein uses 10.10GByte and SETI 54,47MByte on this host.
Oh well, SETI work is finished but can't report or UPLoad, a.t.m..
Oh well, SETI work is finished but can't report or UPLoad, a.t.m..
Three hosts all doing Einstein now.
Actually, Seti's upload server is on. Check your Transfers tab and your messages. Uploads are just fine. (So are downloads, if you have have any left you never downloaded.) I wish they'd turn on data-driven web pages, at least the forums.
My slower machines have finally gotten some Einstein to work on too, although at least one of them still has a few days' worth of Seti to do.
David
David
Miserable old git
Patiently waiting for the asteroid with my name on it.
(So are downloads, if you have have any left you never downloaded.)
If you had any left that you never downloaded, that implies ghosts. And the only way to get the resends is after a scheduler contact, which isn't going to happen as the scheduler is off-line.
The only way you could get downloads in, is if they were busy when the power went out at Seti and they were in extended back-off of a retry. But then they would've been in already ass the download servers have been up for the past few days. :)
Quote:
I wish they'd turn on data-driven web pages, at least the forums.
That requires (BOINC) database access and there's a good chance that that's corrupted in some way due to the power outage happening without warning.
RE: RE: A week or two
)
Actually, his older BOINC client v6.10.60 is sending back the old-style "Exit status -233", which even the older web server code here ought to have rendered using
#define ERR_UNSTARTED_LATE -233RE: RE: I'm looking for
)
Yes, I've seen that. I was hoping someone would have been in touch with Eric or somebody and know more. Like why the estimate is Tuesday instead of yesterday afternoon.
David
Miserable old git
Patiently waiting for the asteroid with my name on it.
RE: RE: RE: A week or
)
That's what I pretty much figured, but why did it get so much in the first place?
So back to the point I was making in this particular thread, that may be what happened to the anonymous user the OP is referring to.
Would it really behoove me to upgrade my Boinc clients?
David
Miserable old git
Patiently waiting for the asteroid with my name on it.
RE: That's what I pretty
)
The most probable cause was:
When you switch form SETI to E@H your caches probabily are set for normal SETI big number of days and your resource share must be set to 100 (the E@H defoult).
Then what the scheduler does? It´s job and try to fill the caches to their target number of days, because E@H allways have a large number of WU avaiable to DL, they DL faster than SETI WU. So that the main reason what you get so much on the begining. As the time pass the scheduler start to balance that on what you set on the resource share
You could avoid that with a combination of small caches and/or changes in the resource share number.
After BOINC 7.0.28 was
)
After BOINC 7.0.28 was available, I installed it on
,my 3 hosts.
Each running multiple projects, CPU only, CPU+GPU and GPU 'only*'.
*(CPU is always needed).
Unfortunatly my health is very poor and haven't been active on
whatever forum, since a month orso.
BOINC is managing quite well.
I understand Denis Puhar's reaction on the aborted work, but as was pointed
out clear, aborting is 'better',compaired to 'timing out', less 'waiting-time'.
And you're 'daily-quota', will suffer from such an action. Not much
serious harm done here, IMHO.
B.t.w. Einstein is doing very well in Computing Power, as I read.
I'm also amazed by the work done by 16 CPU (cores) and 4 (2x AMD/ATI HD5870
GPU's and a GTX480 & 470, with a 25% Recource Share
Well, Keep on Crunching ;^).
RE: RE: That's what I
)
Actually, my resource shares are 110 Seti, 30 Einstein (and 60 Orbit, but it never has any work and is suspended on that machine).
David
Miserable old git
Patiently waiting for the asteroid with my name on it.
RE: Actually, my resource
)
Any number diferent from 0 (zero) will make the cache fill to the maximum, it allways try to keep your host feeded, thats it´s jobs. The problem is with the with the lack of SETI WU.
RE: RE: Actually, my
)
Well I use a 3 day and additionel 2 day cache works OK, especially when you're
doing both Einstein and SETI, otherwise you'll be flooded with Einstein work ;-)
Einstein also uses quite a lot of storage, compaired to SETI.
Einstein uses 10.10GByte and SETI 54,47MByte on this host.
Oh well, SETI work is finished but can't report or UPLoad, a.t.m..
Three hosts all doing Einstein now.
RE: Oh well, SETI work is
)
Actually, Seti's upload server is on. Check your Transfers tab and your messages. Uploads are just fine. (So are downloads, if you have have any left you never downloaded.) I wish they'd turn on data-driven web pages, at least the forums.
My slower machines have finally gotten some Einstein to work on too, although at least one of them still has a few days' worth of Seti to do.
David
David
Miserable old git
Patiently waiting for the asteroid with my name on it.
RE: (So are downloads, if
)
If you had any left that you never downloaded, that implies ghosts. And the only way to get the resends is after a scheduler contact, which isn't going to happen as the scheduler is off-line.
The only way you could get downloads in, is if they were busy when the power went out at Seti and they were in extended back-off of a retry. But then they would've been in already ass the download servers have been up for the past few days. :)
That requires (BOINC) database access and there's a good chance that that's corrupted in some way due to the power outage happening without warning.