ok THANKS !!!!!!

uploading :)

---

SETI@Home Informational message -9 result_overflow
with a general handicap of 80% and it makes much d' efforts for the community and s' expimer, thank you d' to be understanding.

now thats the kind of info we need on the front page, something as simple as use HTTP proxy 128.32.18.137 for now.

I would only use it for as long as needed to clear your cache, and then go back to 'normal.' Having many, many users keeping the proxy setting for long periods could cause all sorts of problems with the server.

BTW, excellent bit of detective work on finding that work-around!

Done and done!!!

All results uploaded, WUs downloaded and proxy reset to normal.

Excellent workaround.

---

Final Classic total: 11446 WU
Classic CPU hours: 72,366

The proxy workaround simply implies the berkeley guys have a major DNS-problem. Hope someone with networking knowledge reads this and pulls the right strings to get this working again...

---

Aloha, Uli

A quick tip before I turn in for the night.

Try connecting via HTTP proxy 128.32.18.173 in the tools>options tab

I had well over a hundred WU waiting to upload (actually probably many more, but I didn't count them). They zipped through, a bit slower than normal, but with no dropped connections, downloads too.

I now have a full Seti cache on all machines and have set Einstein back to a very low priority.

Hail yeeah. TWO EMPTY TRANSFER QUEUEUEUEUS (man I hate typing that word)

YOU ROCK!

(j)
James

PS - Um, that didn't work for me. And if it works for you, please forget it promptly and tell no one... (trying to keep traffic on my new favorite proxy down!) 8)

Uli, partially agree

The proxy workaround simply implies the berkeley guys have a major DNS-problem. Hope someone with networking knowledge reads this and pulls the right strings to get this working again...

DNS Implies that connections Host Names to IP are incorrect and would be an even larger problem... Their Internal Servers are handing off from scheduler to other machines for Upload/Download...

This was a topic of previous posts and various "Proxies" were a workaround for those cutoff in Europe...

Whether you use a direct connection or a proxy the end connection IP address is the same... The Proxy would tend to be more tolerent of network connection timeouts and number of retries... But that was brought up ages ago... So it could be that the "network timeout/retries" should be looked at UCB...

As I plugged the Proxy address into one machine, it was noticable that the "retry in xx:xx:xx hrs:Min:Sec" returned in seconds rather than minutes...

R/

Al

---

Please consider a Donation to the Seti Project.

The proxy workaround simply implies the berkeley guys have a major DNS-problem. Hope someone with networking knowledge reads this and pulls the right strings to get this working again...

This is true, unless they put that in on purpose... I'd have to look at some netstat data (since I have no more queued results) to be sure. But it's *possible* that they stuck in a couple dead-end addresses in DNS to slow down the clients. Or, they could just have problems.

Depends on if you think the S@H crew is more on top of it than not. As I've seen over the last few days, opinions vary...

double post. sry.

Uli, partially agree

The proxy workaround simply implies the berkeley guys have a major DNS-problem. Hope someone with networking knowledge reads this and pulls the right strings to get this working again...

DNS Implies that connections Host Names to IP are incorrect and would be an even larger problem... Their Internal Servers are handing off from scheduler to other machines for Upload/Download...

This was a topic of previous posts and various "Proxies" were a workaround for those cutoff in Europe...

Whether you use a direct connection or a proxy the end connection IP address is the same... The Proxy would tend to be more tolerent of network connection timeouts and number of retries... But that was brought up ages ago... So it could be that the "network timeout/retries" should be looked at UCB...

As I plugged the Proxy address into one machine, it was noticable that the "retry in xx:xx:xx hrs:Min:Sec" returned in seconds rather than minutes...

R/

Al

I Agree with you. Moreover, the proxy address (128.32.18.173) happens to be galileo, the scheduler itself. If we are successfully reaching the scheduler (a software component) using a wrapper (the proxy) in the very same machine, this might indicate that some tunning is needed in the scheduler code.

All this is just speculation, as I am no expert in these topics. I just tracert'd to the given proxy address and found that it was galileo.


Roberto.

---

Your assessment is sound. I plugged it into three machines and they drained 70 WUs each in about 10 minutes, so a code-check is probably in order... :o)

---

Stewie: So, is there any tread left on the tires? Or at this point would it be like throwing a hot dog down a hallway?

Fox Sunday (US) at 9PM ET/PT

Hi,

I now managed to finish upload of aprox 200 WU's with this 'workaround' and downloaded even more units (raised the WU cache to 10 days) in aprox one hour.

The uploaded WU's are now in the pending credit mode.
/edit: You can all see your own pending-stats here on this fine site:Pending Credits for BOINC Projects

Kiva

---

Greetings from Norway

Crunch3er & AK-V8 Inside

In this case the proxy has process/connection threads that it can spawn... Scheduler is "generally" overloaded and waiting for network timeouts... So as it happens that is this case Scheduler responds to a application/proccess that is not overloaded... One only has to wonder at what other misconfigurations that are plauging the project with no answers... This was a question I asked weeks ago what happened to "change something" after it was stated in Tech News that upgrades were applied and configurations may have been overwritten... The Admin has control over the number of processes/connections and timeouts that are "allowed" tuning allows the admin to run one number up and one number down... "Defaults" are often well below what the server is capable of...

Uli, partially agree

The proxy workaround simply implies the berkeley guys have a major DNS-problem. Hope someone with networking knowledge reads this and pulls the right strings to get this working again...

DNS Implies that connections Host Names to IP are incorrect and would be an even larger problem... Their Internal Servers are handing off from scheduler to other machines for Upload/Download...

This was a topic of previous posts and various "Proxies" were a workaround for those cutoff in Europe...

Whether you use a direct connection or a proxy the end connection IP address is the same... The Proxy would tend to be more tolerent of network connection timeouts and number of retries... But that was brought up ages ago... So it could be that the "network timeout/retries" should be looked at UCB...

As I plugged the Proxy address into one machine, it was noticable that the "retry in xx:xx:xx hrs:Min:Sec" returned in seconds rather than minutes...

I Agree with you. Moreover, the proxy address (128.32.18.173) happens to be galileo, the scheduler itself. If we are successfully reaching the scheduler (a software component) using a wrapper (the proxy) in the very same machine, this might indicate that some tunning is needed in the scheduler code.

All this is just speculation, as I am no expert in these topics. I just tracert'd to the given proxy address and found that it was galileo.


Roberto.

R/

Al

---

Please consider a Donation to the Seti Project.

For what it is worth, I sent a note in about this. And yes, it does seem to work. Though I did get about 5 timeouts, I cleared my back log.

So, it has been reported. Though one of the obvious responses is to change the server so it will not act as a proxy ... it may not be what is desired by most ... :)

---

Yes, the proxy worked for exactly 1 WU, now it's as dead as the rest of this *censored*... :/

I got it to upload for exactly 2. However, those wont report.

Try connecting via HTTP proxy 128.32.18.173 in the tools>options tab

Just wanted to thank Nightlord for that, it worked splendid :)

Greetings from Sweden

---

Greetings from Sweden

A quick tip before I turn in for the night.

Try connecting via HTTP proxy 128.32.18.173 in the tools>options tab

Thank you, poster of the month ([b]Nightlord</B>).


P.S. Matt Lebofsky has a new message on his SLog.

---

Proxie worked for me as well. Have a few units to complete that were "downloading" for last couple of days, they have downloaded and everything else has uploaded finally.

---

Team MacNN - The best Macintosh team ever.

This whole thing just indicates that there is a big problem with routing or DNS/Bind. An important thing to note is that an IP address is being used to return results and not a "friendly name". It might well be that using an IP address (without a proxy of any sort) might also work.

Anybody tried using a "friendly name" and not an IP address in the proxy setting? Did it work?

---

I don't think it is as nefarious as you all seem to think it is.

Basically the proxy headers are ignored by the web server and the request is processed just like it was any other web request. It just so happens that the cgi directory is mapped to the same location on both servers. So when an HTTP request is made for the file_upload_handler it executes the file_upload_handler on galileo instead of kryten.

The upload/download directories are also mapped to the same locations as well. So things should work.

I have sent mail to Matt and Jeff letting them know what is going on.

Now whether they let it stay that way is another thing.

---

----- Rom
BOINC Development Team, U.C. Berkeley
My Blog

WOW!

this is like driving in the HOV lane, blowing past 5 lanes
of gridlock.

Are we going to get pulled over for cheating, or is the
blowup doll in the passenger seat going to keep us legal?

In answer to azwoody:

If by "friendly", you mean "galileo.ssl.berkeley.edu" rather
than the numbers, yes, I used that.

Of my farm of 3 (OK, maybe "bean patch" rather than farm) one
of them could not connect at all using the numbers ("can't
resolve host name"). Dunno why it had to be different.

So I put the name in rather than the numbers, and that host
joined the others in perfect connects - every ul/dl attempt
completed first time after configuring for the proxy. All
my backlog which had been retrying for the last 24 hours, with
only a very slow rate of real progress, was gone in a snap.

Dave

Now THAT'S a tweak!

I've just uploaded over 20WUs in less than probably 30 minutes :) Can't complain about that!!

Puffy

---