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

Bruno -up :-) happy day

If I could be at Bruno's place right now, I certainly wouldn't be so happy ... lol

---

Who the hell is General Failure and why is he reading my harddisk?¿

Greetings!
Have similar problems doing upload since Sunday.
(Have 10 WU that are getting the -107 status)

I would like some guidance.
How long is a 'normal' (bwaahaaahaaa) wait-time to get a chance for an upload to succeed????

In the meantime, I have tried several things.
With my luck, they made things worse.

I have tried:
- rebooting the PC
- trying a ping to setiboincdata.ssl.berkeley.edu ( Ping was OK:
10 bytes from 208.68.240.16: icmp_seq=0 ttl=46
10 bytes from 208.68.240.16: icmp_seq=1 ttl=46
- set DNS cache TTL to 16 seconds
- tried upload with antivirus turned off.
- waited through the Tuesday outage for backup. But its Wednesday now...
- Looked at the seti I/O graphs (THANK YOU) to see when there is a 'normal'
amount of load


Suggestions are welcome.

Environment stuff
7/15/2009 12:09:26 PM Processor: 2 GenuineIntel Intel(R) Core(TM) Duo CPU T2300 @ 1.66GHz [x86 Family 6 Model 14 Stepping 12]
7/15/2009 12:09:26 PM Processor features: fpu tsc pae nx sse sse2 mmx
7/15/2009 12:09:26 PM OS: Microsoft Windows XP: Professional x86 Edition, Service Pack 3, (05.01.2600.00)
7/15/2009 12:09:26 PM Memory: 2.00 GB physical, 3.84 GB virtual
7/15/2009 12:09:26 PM Disk: 107.41 GB total, 85.03 GB free
7/15/2009 12:09:26 PM Local time is UTC -4 hours
7/15/2009 12:09:26 PM No CUDA devices found
7/15/2009 12:09:26 PM No coprocessors
7/15/2009 12:09:26 PM Not using a proxy


Here is a snap of some upload messages (There are 2 overlapping uploads)
7/15/2009 12:11:16 PM SETI@home Started upload of 01dc08ad.14412.13569.8.8.222_0_0
7/15/2009 12:11:16 PM SETI@home [file_xfer_debug] URL: http://setiboincdata.ssl.berkeley.edu/sah_cgi/file_upload_handler
7/15/2009 12:11:18 PM Internet access OK - project servers may be temporarily down.
7/15/2009 12:11:38 PM Project communication failed: attempting access to reference site
7/15/2009 12:11:38 PM SETI@home [file_xfer_debug] FILE_XFER_SET::poll(): http op done; retval -107
7/15/2009 12:11:38 PM SETI@home [file_xfer_debug] FILE_XFER_SET::poll(): http op done; retval -107
7/15/2009 12:11:38 PM SETI@home [file_xfer_debug] file transfer status -107



Thanks again,
Jay

Now that the server is back online, lets all upload at the same time :-)
THNX, Seti (Matt)

If simplex is the main issue on the connection, a possible (work around) solution could be to switch upload and download servers on-line and offline with a window of 24 hours or so.

In my opinion, this would actually be worse. The BOINC client doesn't have a way to know that "monday is download day" and will keep trying to upload.

The best way to avoid getting hammered on uploads is to take them -- then they don't come back later.

---

Yes.. the UL server is now green..
http://setiathome.berkeley.edu/sah_status.html

BUT, I can't upload..

---

You'll have to get in line with everyone else.

---

Thanks Bill Walker and SuperJoker. It certainly makes sense but how about relaxing the linking rule under special circumstances like this. Would that be a feasible option?

---

Bruno -up :-) happy day

If I could be at Bruno's place right now, I certainly wouldn't be so happy ... lol

True!, but we are going forward, (may be, for the moment ) :-)

---

"The longest journey begins with a single step" Confucius

i have been letting my pc work for seti for a few years now
But often my pc does nothing becouse of problems with upload download no work avalible etc etc etc
Are there to many people helping? its rather anoying to find out in the mornig my pc was on all night for nothing once again.
And it does not seem to get better but worse treu the years

greetings from Holland
Erik Muller

---

Suggestions are welcome.

Next time, check the server status page first - a server was disabled until about half an hour ago.

It's always a good idea to do whatever you can to distinguish whether it's a problem at 'your end' or 'their end'. Sometimes people complain about the project servers being down for weeks on end - and it turns out to be a problem on their own computer.

This time, it was a problem at the project's end - and no amount of fiddling with your computer is going to overcome that.

You'll have to get in line with everyone else.

???

I don't know what you mean.

I have now maybe ~ 1,600 results ready for UL.

And after every few seconds an other result would like to start the UL, but can't and a new one start and can't also reach the UL server.

I guess it's now again a prob with DNS, http or what ever.
With my ISP from Germany - I can't reach the UL server.

---

What is the harm in allowing downloads if the work is available.

... because downloads eventually become uploads, and if uploads are a problem, you don't want to add to it.

---

Well, it's no better in Southern California either. Seems to be the same thing as yesterday when supposedly the upload server was up during the maintenance. 4 pc's and not one uploaded. Hang in there, we'll get there.

---

Thanks Bill Walker and SuperJoker. It certainly makes sense but how about relaxing the linking rule under special circumstances like this. Would that be a feasible option?

"Circumstances like this" are exactly why you want to link uploads and downloads.

Trouble uploading + more downloads + time means even more upload problems later.

---

I have now maybe ~ 1,600 results ready for UL.

Your machine has 1,600 results, and it tries to connect 1600 times every four hours, more or less, depending on the backoff.

How many others out there have lots of uploads, and are retrying just as aggressively?

---

Ok. I give up. There seems no room for any creative ideas :)

---

@ Byron S Goodgame

Of course, I'm patient.. I'm a SETI@home member.. ;-)

My GPU cruncher have still maybe two days WU cache.. I hope in this time the UL server will be reachable and new work will be available.. :-D

---

As usual, Ned has a good point.

Also, I belive the "linkage" occurs in BOINC, not just in SETI. Even if disabling the linking would help now, it would defeat the concept of BOINC being universal if each project could start manipulating it to work around their unique issues.

NEWS FLASH - I just had one WU upload! Only about a dozen left now...

15/07/2009 1:04:50 PM SETI@home Finished upload of 24fe09ab.20328.11115.5.8.44_3_0

---