Get them more coffee!! Can't hurt, might help.

hey..... when did they get the money for coffee? :D

They didn't - that's the problem.

We supply the coffee, they supply the WUs - fair swap?

They didn't - that's the problem.

We supply the coffee, they supply the WUs - fair swap?

It seems that coffee alone might not solve the problem. We might have to toss in a few doughnuts as well. Maybe a tuna sandwich or two.
______________

They didn't - that's the problem.

We supply the coffee, they supply the WUs - fair swap?

It seems that coffee alone might not solve the problem. We might have to toss in a few doughnuts as well. Maybe a tuna sandwich or two.

There is a rumour that beer works best in Matt's case. Still have to research his taste in sandwiches.

I have been looking at this:

http://setiathome.berkeley.edu/sah_status.html

and this:

http://bluenorthernsoftware.com/scarecrow/sahstats/graphs.php?t=48

and this:

http://fragment1.berkeley.edu/newcricket/grapher.cgi?target=%2Frouter-interfaces%2Finr-250%2Fgigabitethernet2_3;view=Octets;ranges=d%3Aw%3Am%3Ay

If the bandwidth was being used by CUDA, the turnaround time would not be rising. If the bandwidth was being used by so-called older, slower machines would the "bytes out" not be higher? If it's database queries the "queries/sec" would be much higher.

So, is it possible that "ACK" (hey, other computer, are you there and can we talk) is accounting for 30-40Mbits/sec of bandwidth?!?! If so, it certainly would explain the congestion and dataflow problems of late.

BTW - I am a 10 year member and have gone through a lot of "bumpy" periods. No WU's gets me going, too. But how would you like to be Matt? Everyone screaming about the equivalent of not being able to live in a mansion on a paupers wages. And he is still nice enough to do the tech updates so we all can have a idea of what's going on at the other end (even if sometimes it's after the fact).

Oz

---

Member of the 20 Year Club

Is there any prognosis on poor Bruno's condition?
Any estimate on when he will recover?

181 tasks in "Uploading - Retry in xx:xx:xx" at this time.

---

Please be patient..

I'm patient also.. I'm a SETI@home member and learned this property.. ;-)

Also I ran out or work more times.


AFAIK, ONLY the UL server is offline.
O.K., also some splitters but they are current not soo important.
http://setiathome.berkeley.edu/sah_status.html

I don't know why and don't know how long it will last..
But the Berkeley crew know why. They have a well reason for this.

O.K., it's sadly that Matt didn't found time to update the TNews [http://setiathome.berkeley.edu/forum_forum.php?id=21].. but for sure he will post there soon.

Yes.. I have now 1 1/2 day results for UL and they can't go home.
BOINC is now nearly unusable with so many results in the UL overview.. so I guess it should be ~ 1,200 WUs or more..
The GPU cruncher make ~ 800 WUs / day.

I have a ~ 4 day cache, so I hope I can UL the next one, two days.
> 'CPUs x 2' ULs in BOINC and no work request.


O.K., SETI@home member, please don't condemn the project or don't be angry..
The Berkeley crew make the best for to be online again.


BTW. AFAIK. SETI@home have ~ 50 % or more of all BOINC members, right?
So SETI@home have the most server traffic of all BOINC projects.
Sometimes other projects have also server probs, which have less members.

Please be patient and soon we have all again new WUs.. :-)



BTW.
SETI@home is a nonprofit educational and research organization that relies significantly on donations to continue operations.
http://setiathome.berkeley.edu/sah_donate.php

---

I am down to my last one I must have had a slight problem with my internet as Boinc said check internet or proxy and a few seconds later it tried to upload an old wu. has anyone idea what is causing this slight problem could there have been a problem with my ISP that corrected itself after a few seconds. This is twice I have had this simce updating to 6.6.20

---

I don´t mind if I can´t upload my results for over a week or more. But having idle machines that can´t download more work because the out pile is full, while work to distribute and process increase, that don´t make any sense to me.
There is any work around this "feature"?

---

hello.
Since more than 24 hours impossible to transfer the completed work.
I do not include/understand because I continue to receive work.
20 WU finished and in a state of transfer.
The newspaper of BOINC n' do not stop growing bigger.
Always the same message: Internet access OK - project servers may Be temporarily down Thank you very much to inform of this message the server, in order to solve this problem....

Uploads have been disabled temporarily. The SETI Admins are working towards a solution as best they can.

---

I don´t mind if I can´t upload my results for over a week or more. But having idle machines that can´t download more work because the out pile is full, while work to distribute and process increase, that don´t make any sense to me.
There is any work around this "feature"?

There are lots of other projects out there that would love your main crunchers do work for them if even temporarily. I put as much work as I can with S@H but when it runs out like it has on my 2 CUDA enabled machines I load up a WU from CPUGRID and my card is happy for hours. Yes I'm not crunching for that day or 2 on Seti but I am still contributing to a BOINC project just the same and it all adds up in the combined BOINC totals.

If you are unwilling to attach to other projects then I guess the big red power button is the way to go. The guys in the lab will get things up and going when they can.

---

http://www.novascotia.com

I see that the status of the upload server has been disabled now since at least yesterday.

Anybody know why, and when it will be back up?

Yes, it's disabled.
No, we don't know why.
No, we don't know when it will be back.

Plenty of threads about that around here. :-)

---

This is due to bandwidth/server issues and very high traffic from clients trying to upload. This seems to be a chronic recurring problem for SETI@HOME. The project is not managed very well and there appear to be more volunteers and number crunching power than they can handle. More details are in the following threads:

http://setiathome.berkeley.edu/tech_news.php
http://setiathome.berkeley.edu/forum_thread.php?id=54631

<<<<<<< Hope Bruno is better soon :-)

---

"The longest journey begins with a single step" Confucius

Yes the upload server is disabled since Monday. My computer has a few hundred results waiting to be uploaded and it is running out of work fast. But I don’t understand the logic of linking downloads with uploads. What is the harm in allowing downloads if the work is available.

---

No panic here. The old P4 ran out of work and wont get any im sure, with 7 trying to upload, so i think ill turn that off and let that old CPU cool down and take a well deserved rest. The mac has only a .25 day cache, but i still have at least 2 or 3 days crunching, yep ton of uploads but they will get going when they can.
So in the mean time the mac will have free run of doing Milkyway. I really want to crack that 100.000 mark.

---

[/quote]

Old James

As I understand it, the "linking" is done to cover lots of other possibilities, like problems in the user's computer or in the connections between the user and the project. You don't want the project sending units to a computer that won't recieve them or can't process them. This would waste the project's resources, and could result in work units timing out at the users end.

Right now, the uploads have probably been disabled while the SETI guys try to set up some new configuration on their end to work around our bandwith problems. Or, it may be a hardware problem at SETI. In either case, it will eventually be resolved. In the mean time, try another BOINC project and (as I am about to do) have a cup of tea.

---

I am down to my last one I must have had a slight problem with my internet as Boinc said check internet or proxy and a few seconds later it tried to upload an old wu. has anyone idea what is causing this slight problem could there have been a problem with my ISP that corrected itself after a few seconds. This is twice I have had this simce updating to 6.6.20

I'm using 6.6.36 on one of my pc's and it's been happening to that one too. The rest of the pc's that use other versions don't seem to have that problem, but on the one that does, it seems to be happening more lately. I had thought I'd read someone else having the same problem, but I was leaving at the time, and didn't read all of it and can't find it now..Nothing wrong with the connection, and it only seems to happen when there are server problems.

---

I have been looking at this:

http://setiathome.berkeley.edu/sah_status.html

and this:

http://bluenorthernsoftware.com/scarecrow/sahstats/graphs.php?t=48

and this:

http://fragment1.berkeley.edu/newcricket/grapher.cgi?target=%2Frouter-interfaces%2Finr-250%2Fgigabitethernet2_3;view=Octets;ranges=d%3Aw%3Am%3Ay

If the bandwidth was being used by CUDA, the turnaround time would not be rising. If the bandwidth was being used by so-called older, slower machines would the "bytes out" not be higher? If it's database queries the "queries/sec" would be much higher.

I expect almost all the faster hosts have too many pending uploads to allow work fetch. A bit of statistical analysis I did about a week ago indicated that the top 10000 hosts do about 39% of all work, so even if they're all cut off there's a lot of crunching power still. The average RAC across all 292000 active hosts is around 216, and a host with RAC under 200 because it's doing multiple projects might not be cut off from SETI work yet. Enough hosts are cut off that demand is less than production, though.

So, is it possible that "ACK" (hey, other computer, are you there and can we talk) is accounting for 30-40Mbits/sec of bandwidth?!?! If so, it certainly would explain the congestion and dataflow problems of late.

No, with less than 4 MBits/sec going to SSL handshake data on the download side would be about the same. That 30-40 MBits/sec of download is mostly WUs being delivered to hosts which are still able to request work. For instance, an older host which is approaching the end of an AP_v505 WU it got a week ago would have no results awaiting upload. Because a "Results ready to send" queue has built up for both types of work, the ratio should be about 32:1 MB:AP_v505 work going out. 7 or 8 MB WUs and 1/5 to 1/4 of an AP_v505 being downloaded each second would give the shown download rate.

Bruno -up :-) happy day

---

"The longest journey begins with a single step" Confucius