If you mean the latest BOINC version, be advised it has greatly increased retry and backoff escalations and maked uploads & downloads more trying. That's what made me go back to 6.10.xx - I'm not recommending that others revert-- I had another problem -- but I'd hesitate to upgrade when you're having file transfer problems.

---

Another Fred
Support SETI@home when you search the Web with GoodSearch or shop online with GoodShop.

I get many HTTP errors now, while if connection succeeds - download speed quite good.
It's unusual, on saturated network bandwidth I usually see low download speeds if connections dropped so often.
Smth wrong with server setup now ?

My up and downloads seem to be going through okay. Haven't been watching to closely but not much problem. Maybe they will get everything organized during the weekly outage coming soon and we can enjoy some really good uptime.

---

PROUD MEMBER OF Team Starfire World BOINC

Okay, update on my end...three linux boxes uploading and downloading just fine
from work...crappy connection but working. two windows boxes - xp and 7, not
uploading at all from home, fast connection. Upgraded the win7 box to the
latest boinc still no go.

---

"Two things are infinite: The universe and human stupidity; and I'm not sure about the universe." - Albert Einstein

Outage over, so let's introduce a new one:

22/06/2011 00:33:44 SETI@home Message from server: Resent lost task 08ap11ac.12708.16836.16.10.130_0
22/06/2011 00:33:44 SETI@home [error] Already have task 08ap11ac.12708.16836.16.10.130_0

What's next :-) ?

---

Morten Ross

Yesterday (Monday) I hammered my two uploads through. I had let them try on their own for nearly 24 hours and after 14 minutes of elapsed time trying to upload, hammering the retry button a few times seemed to work.

---

Linux laptop:
record uptime: 1511d 20h 19m (ended due to the power brick giving-up)

Whatever they did during the outage seems to have sorted the upload problem. After the outage there was a big surge in uploads, then it tapered off to normal levels, instead of gradually rising & falling & meandering about while the uploads kept timing out.

---

Grant
Darwin NT

Oh, well.
Here we go again.
The server status page quit updating about 45 minutes ago, and uploads get no connect errors.
Time for the kittyman to go to bed anyway.

Meowsigh.

---

"Time is simply the mechanism that keeps everything from happening all at once."

What is it about 24:00hrs Berkeley time?
For a while there, uploads & downloads dropped to nothing, and the Seti site was unreachable. Downloads & this site are back up, but uploads once again are no go.

---

Grant
Darwin NT

Its the midnight blues. Which I could sing, but you know what happened in NZ a few weeks ago, minutes after my last rendition......

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

UL don't work.


Ohh.. - what.. - what's with our loved project??

Every ~ 2 days server outage..

It's a hard-/ or software problem in the server lab?

It's again time for new equipment?


- Best regards! - Sutaru Tsureku, team seti.international founder. - Optimize your PC for higher RAC. - SETI@home needs your help. -

---

Yes, something happens.
Uploads are slow even there´s no heavy load on Bruno.
Nothing since 7 AM UTC.

Monthly cricket graph doesn´t look well.

But i´m sure the staff is doing their best to resolve it.

---

With each crime and every kindness we birth our future.

Confirmed no uploads from UK, but cricket graph looks OK.

Cricket graph looks broken to me.
At 24:00hrs Berkeley time everything died briefly. Downloads & this site came back up, but uploads didn't. The upload traffic you see in the graphs at the moment is just the acknowlegements from the download traffic & Scheduler requests/ reporting. No completed results are getting through.

---

Grant
Darwin NT

I think We did a DDOS attack on Seti, by accident.

---

Savoir-Faire is everywhere!
The T1 Trust, T1 Class 4-4-4-4 #5550, America's First HST

I think We did a DDOS attack on Seti, by accident.

Not by accident, by design, (of the new x38g, and ATI crunching)

LOL

Edit: I think we've reached roads end so to speak, when it comes to the current server setup. Crunching computers are getting faster and faster, and now with x38g, as well as thousands of computers being able to run SETI on their ATI cards, we're literally killing the current server setup.

Hmmm....Makes me think that if the splitters were reworked to make bigger chunks that would take a little longer to process, this might alleviate a little of the network traffic as well. Fewer WU to report means fewer connections and less traffic. Should be a quick and easy "fix" for at least part of the issue. it would mean slightly larger/longer transmits but much fewer of them.

Fire reTARDant suit is neatly pressed and zipped up - feel free :)

Kevin - The Pirate robotic Super (Sq)uirrel :)

---

"Two things are infinite: The universe and human stupidity; and I'm not sure about the universe." - Albert Einstein

And yes, maybe it is time to leave the oldest computers back in the dust, by increasing the analyzis time even further, and not extending the deadline.

For the first, I don't think that old computers returning maybe 1 WU per week are causing the current problems.

Than I also don't hope, that the project will increase the analysis time just for to keep our CPUs and GPUs warm. You always reach a point, where further increase of accuracy becomes pointless for the science (unlike implementing of new search methods like the correlation thing in v7). I don't know i SETI has already reached this point, but if it is so, than better slow down the splitters and send out less work, anything else would be just waste of resources which can be used by other projects. So, yes, increase, but only if it actually help us to find ET.

---

Aw, come on now.
It was just that dang midnight cleaning crew plugging their vac into the wrong outlet again.

---

"Time is simply the mechanism that keeps everything from happening all at once."

By the looks of things, we will never again get back to the situation we had before, when the cricket graph would fall to sustainable levels 1-2 days after the weekly outage. As of now, it's maxed all the time the servers can sustain the beating, and then that follows time after time by some server failure, RAID failure, or other issues.

I'm not so sure this is the case. What I have seen lately is an unusual amount of 'shorties'. When the ratio of 'shorties' drops back to levels I noticed before a lot of the problems will be gone. On my GPU I can do at least 4 shorties in the same time it takes to process a single 'long' workunit. Now there will always be some shorties so you can't expect the number of workunits processed (needing both bandwidth and transaction resources for processing) to go down be a factor four, but I think a factor two should be possible. Maybe the servers and the internet connection can keep up again when this happens ...

Tom

Well, of course there has to be some gain in the science too, we can't increase crunch times just for the sake of slowing things down. If we can't do that, then maybe other ways can be found to ease the burden on the servers. Maybe as you say send out less work, or maybe run the system 100% full bandwidth for 2 hours, and then shut down all outside contact (perhaps allow only uploads) for 1 hour, so the servers can catch up with the work they received during the 2 hours they were working 100%, and then repeat that cycle....

According to how the system was performing until... not so long time ago... I think slowing down the feeder just a bit would be enough.

I also don't think the recent "crashes" are caused by hardware failures as those usually happen at any time and not preferably around 7:00 UTC or whenever the other 1 or 2 sheduled crashes used to happen.

---

I also don't think the recent "crashes" are caused by hardware failures as those usually happen at any time and not preferably around 7:00 UTC or whenever the other 1 or 2 sheduled crashes used to happen.

Well, then they'd better try to find out what is happening in the lab at 7:00 UTC. I agree with you that is is indeed very strange that many of the "crashes" recently have all occured at more or less exactly 7:00 UTC, and that is not normal for any hardware problem, to always happen at the same time.

I think the last time they were having a problem with 'regularly scheduled' crashes it was tracked down to a UPS with failing batteries...
Might there be another one in the loop somewhere?

EDIT...
It might also be a good idea to borrow a power quality monitor (I'd be surprised if there was not one available somewhere on campus) and monitor the incoming power for any unusual spikes, sags, etc. that could be causing the grief.

---

"Time is simply the mechanism that keeps everything from happening all at once."