I have 2 WU to be uploaded, since three days !!! Each time the upload starts, the transfer speed is 0.07KBS ! What is this ? I removed/erased the firewall ! No change ! The browser (Safari) works fast, Mail transfers fast, when I upload to .Mac, it goes fast ! It does not seem to come from my machine but from Seti receiving computer ! How can we alert people at SETI so that they unlock/debug the receiver ?
I also run Einstein@home and this one transfers OK !
There should be a way to contact people at SETI ! Does someone know an address/phone/fax/something ?
Probably a little late to suggest this, but, perhaps doing a rolling change over instead of picking a drop dead date causing everyone to headfor the exit or entry at the same time would reduce the bottlenecks.
Probably a little late to suggest this, but, perhaps doing a rolling change over instead of picking a drop dead date causing everyone to headfor the exit or entry at the same time would reduce the bottlenecks.
Seti BOINC has been around for about a year now and the Seti website has been encouraging everyone to switch for as long as BOINC has been in existence.
OK - I selected " No New Work " and will crunch wich Einstein then !
In a week, I'll retry ! I imagine that if EVERYBODY keeps ping-ing SETI, that will not help their server !
Out of curiosity, why don't the SETI folk suspend all new work downloads and focus on servicing uploads of completed work? With no new work being sent out, the glut would have to start clearing sooner or later.
I think you'll find if you check their website, this exact policy is now being followed. Things must be a bit desperate because usually there is a bigger outcry for no available work than there is for just uploading difficulties. People need to work out how to help Seti. One way is to stop DOS'ing them.
OK - I selected " No New Work " and will crunch wich Einstein then !
In a week, I'll retry ! I imagine that if EVERYBODY keeps ping-ing SETI, that will not help their server !
Sounds like a good plan. If you have anything stuck in "downloading" it is possible for your computer to become idle. In that case, you can avoid the possibility of an idle cpu by also "suspending" the Seti project until things improve.
To anyone who might be concerned that EAH might sink under the new load, please have a look at this post from Prof Bruce Allen who seems to have planned ahead with plenty of reserve capacity in place.
Nope, I'm using 5.2.13, and the problem does occur.
Ok, thanks for that. Good to know the problem is in all recent versions.
Quote:
One thing we could check, though, would be whether the CPU sits idle only for one scheduler interval (the 60-min-default).
Nope. With the 60 minute default and just two projects Seti/EAH, I've seen a box sit idle for around three hours (and counting) before the Seti suspend solved the problem.
Quote:
I had some strange behaviour concerning LHC, where the server wouldn't be checked for work, even when updating manually (see here). But yesterday or so, I noticed that the LHC server *is* contacted every other scheduler interval or so, even though the corresponding LTD is still negative. SETI was *not* suspended and did some work at that time, however.
I've read your report over on BOINC. Are you saying that what you reported on BOINC has now changed to what you are reporting here now that Seti has got its stuck download through and you've "Resume"d it? I wonder if suspending and resuming (perhaps multiple times) might be causing LTD readjustments which somehow result in LHC's LTD to become negative? This negative LTD for LHC is the big puzzle to me. The key lies there somewhere.
Are you saying that what you reported on BOINC has now changed to what you are reporting here now that Seti has got its stuck download through and you've "Resume"d it?
Yes, the LHC server is now being contacted, and the stuck download is gone.
Quote:
I wonder if suspending and resuming (perhaps multiple times) might be causing LTD readjustments which somehow result in LHC's LTD to become negative?
Well, I did have an (unrelated) strange behavior when I suspend all projects one by one, and then reactivate them. Seti and Enstein will switch computation about 10-20 times in a matter of a second or so, then one of them "wins", and computation proceeds normally.
Well, I did have an (unrelated) strange behavior when I suspend all projects one by one, and then reactivate them. Seti and Enstein will switch computation about 10-20 times in a matter of a second or so, then one of them "wins", and computation proceeds normally.
Heheheh... I'd say, "you're pushing BOINC's buttons and getting the predictable reaction" :). It goes craaazzzzyyyyy!!! :).
Seriously, the scheduler is a fairly complex piece of code that does some strange things very occasionally under duress. Most of the time it's pretty impressive considering the huge range of variables and their possible values. If things have basically settled for the moment, please just observe and try to document the conditions under which something unexpected happens. I know this code is still in transition and the sort of feedback you gave over at BOINC will be useful for JM7 to think about.
I have 2 WU to be uploaded,
)
I have 2 WU to be uploaded, since three days !!! Each time the upload starts, the transfer speed is 0.07KBS ! What is this ? I removed/erased the firewall ! No change ! The browser (Safari) works fast, Mail transfers fast, when I upload to .Mac, it goes fast ! It does not seem to come from my machine but from Seti receiving computer ! How can we alert people at SETI so that they unlock/debug the receiver ?
I also run Einstein@home and this one transfers OK !
There should be a way to contact people at SETI ! Does someone know an address/phone/fax/something ?
Alain
RE: There should be a way
)
Maybe a web site? SETI Message Boards - there you will see the 998,775,432 people who are contacting them...
Probably a little late to
)
Probably a little late to suggest this, but, perhaps doing a rolling change over instead of picking a drop dead date causing everyone to headfor the exit or entry at the same time would reduce the bottlenecks.
RE: Probably a little late
)
Seti BOINC has been around for about a year now and the Seti website has been encouraging everyone to switch for as long as BOINC has been in existence.
OK - I selected " No New Work
)
OK - I selected " No New Work " and will crunch wich Einstein then !
In a week, I'll retry ! I imagine that if EVERYBODY keeps ping-ing SETI, that will not help their server !
RE: Out of curiosity, why
)
I think you'll find if you check their website, this exact policy is now being followed. Things must be a bit desperate because usually there is a bigger outcry for no available work than there is for just uploading difficulties. People need to work out how to help Seti. One way is to stop DOS'ing them.
Cheers,
Gary.
RE: OK - I selected " No
)
Sounds like a good plan. If you have anything stuck in "downloading" it is possible for your computer to become idle. In that case, you can avoid the possibility of an idle cpu by also "suspending" the Seti project until things improve.
To anyone who might be concerned that EAH might sink under the new load, please have a look at this post from Prof Bruce Allen who seems to have planned ahead with plenty of reserve capacity in place.
Cheers,
Gary.
RE: Nope, I'm using 5.2.13,
)
Ok, thanks for that. Good to know the problem is in all recent versions.
Nope. With the 60 minute default and just two projects Seti/EAH, I've seen a box sit idle for around three hours (and counting) before the Seti suspend solved the problem.
I've read your report over on BOINC. Are you saying that what you reported on BOINC has now changed to what you are reporting here now that Seti has got its stuck download through and you've "Resume"d it? I wonder if suspending and resuming (perhaps multiple times) might be causing LTD readjustments which somehow result in LHC's LTD to become negative? This negative LTD for LHC is the big puzzle to me. The key lies there somewhere.
Cheers,
Gary.
RE: Are you saying that
)
Yes, the LHC server is now being contacted, and the stuck download is gone.
Well, I did have an (unrelated) strange behavior when I suspend all projects one by one, and then reactivate them. Seti and Enstein will switch computation about 10-20 times in a matter of a second or so, then one of them "wins", and computation proceeds normally.
RE: Well, I did have an
)
Heheheh... I'd say, "you're pushing BOINC's buttons and getting the predictable reaction" :). It goes craaazzzzyyyyy!!! :).
Seriously, the scheduler is a fairly complex piece of code that does some strange things very occasionally under duress. Most of the time it's pretty impressive considering the huge range of variables and their possible values. If things have basically settled for the moment, please just observe and try to document the conditions under which something unexpected happens. I know this code is still in transition and the sort of feedback you gave over at BOINC will be useful for JM7 to think about.
Cheers,
Gary.