I have a strange behaviour here. When updating from my laptop (CC 4.45, WinXP Home) i get those lines:

SETI@home 23.06.2005 08:48:40 Deferring communication with project for 47 minutes and 55 seconds
SETI@home 23.06.2005 08:48:39 Project is down
SETI@home 23.06.2005 08:48:39 Message from server: Project is temporarily shut down for maintenance
SETI@home 23.06.2005 08:48:39 Scheduler request to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi succeeded
SETI@home 23.06.2005 08:48:35 Requesting 0 seconds of work, returning 33 results
SETI@home 23.06.2005 08:48:35 Sending scheduler request to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi

When updating my work-pc (CC 4.45, Win2k) all works well (got new client and work from seti)

I use the same shared internetconnection from both pc's. And other projects still working (Protein and Einstein)

Whats up with the Server???

---

BOINC Doc | Team-Site | BOINC-Podcast

I have a strange behaviour here. When updating from my laptop (CC 4.45, WinXP Home) i get those lines:

SETI@home 23.06.2005 08:48:40 Deferring communication with project for 47 minutes and 55 seconds
SETI@home 23.06.2005 08:48:39 Project is down
SETI@home 23.06.2005 08:48:39 Message from server: Project is temporarily shut down for maintenance
SETI@home 23.06.2005 08:48:39 Scheduler request to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi succeeded
SETI@home 23.06.2005 08:48:35 Requesting 0 seconds of work, returning 33 results
SETI@home 23.06.2005 08:48:35 Sending scheduler request to http://setiboinc.ssl.berkeley.edu/sah_cgi/cgi

When updating my work-pc (CC 4.45, Win2k) all works well (got new client and work from seti)

I use the same shared internetconnection from both pc's. And other projects still working (Protein and Einstein)

Whats up with the Server???

Have a look at the news items on the home page. There have been some short planned outages recently (approx 2 hours) e.g. to add a new table index. BOINC has a cache so that you can carry on crunching during such an outage.

---

Have a look at the news items on the home page. There have been some short planned outages recently (approx 2 hours) e.g. to add a new table index. BOINC has a cache so that you can carry on crunching during such an outage.

I've read this, but i've tried an update from both pc's at the same time. The laptop fails and the desktop succeeds.

btw: the cache is empty, all work is crunched

---

BOINC Doc | Team-Site | BOINC-Podcast

Berkeley recently moved the scheduler to a new server, perhaps the DNS change hasn't propageated to all your systems yet.

Not sure about this, but try, (in a Command Prompt/DOS Box):

IPCONFIG /flushdns

That _may_ get it to try the right DNS entry.

Could also just be an effect of network congestion.
Berkeley have realeased SETI 4.18 which means a 3Mb download to every host.
If so, it should clear in a few hours.

---

Not sure about this, but try, (in a Command Prompt/DOS Box):

IPCONFIG /flushdns

That _may_ get it to try the right DNS entry.

Could also just be an effect of network congestion.
Berkeley have realeased SETI 4.18 which means a 3Mb download to every host.
If so, it should clear in a few hours.

I've tryed this but with no effect. Its realy very strange. One Host says all is right and the other says project down at the same time.

---

BOINC Doc | Team-Site | BOINC-Podcast

Try TRACERT.

You shoud get something like below.
Try it on both systems and see if they following the same route - or at least ending-up at the same place.
The final IP address [66.28.250.124] is the critical bit.

Command Prompt:
tracert setiboinc.ssl.berkeley.edu

Tracing route to setiboinc.ssl.berkeley.edu [66.28.250.124]
over a maximum of 30 hops:


7 19 ms 18 ms 17 ms gfd-bb-a-ae0-0.inet.ntl.com [213.105.172.5]
8 18 ms 18 ms 18 ms tele-ic-1-so-110-0.inet.ntl.com [62.253.185.78]
9 19 ms 18 ms 18 ms 212.250.14.62
10 91 ms 90 ms 91 ms p10-0.core01.bos01.atlas.cogentco.com [130.117.0.46]
11 108 ms 110 ms 109 ms p5-0.core01.ord01.atlas.cogentco.com [66.28.4.110]
12 159 ms 157 ms 157 ms p5-0.core01.sfo01.atlas.cogentco.com [66.28.4.185]
13 160 ms 160 ms 160 ms uc-berkeley.demarc.cogentco.com [66.250.4.74]
14 171 ms 167 ms 171 ms 66.28.250.124

Trace complete.

---

Not really trying to freak you out, but read this post by Ingleside. Now it's very much possible that box is still trying to reach the old scheduler. The one that no longer exists. And as far as I know, the only way around it is to reset the project (a couple of times).

Problem with resetting the project is that you will lose those 33 units you are still trying to report to the server. Something I don't even think a full project backup will correct.

On the other hand, you may want to try uninstalling Boinc, rebooting the PC and reinstalling it. See if it wants to contact the correct scheduler then.

---

Not really trying to freak you out, but read this post by Ingleside. Now it's very much possible that box is still trying to reach the old scheduler. The one that no longer exists. And as far as I know, the only way around it is to reset the project (a couple of times).

Problem with resetting the project is that you will lose those 33 units you are still trying to report to the server. Something I don't even think a full project backup will correct.

On the other hand, you may want to try uninstalling Boinc, rebooting the PC and reinstalling it. See if it wants to contact the correct scheduler then.

Sounds a bit drastic!
If the address is for some reason wrong, and not correcting itself, it can only be a field in one or more of the .XML files that is wrong.
It should be possible to just shut down BOINC and and science apps and edit the appropriate XML files and restart.

---

The address isn't wrong. The scheduler is on the same physical address of setiboinc.ssl.berkeley.edu .. What has changed is the server that the scheduler lives on. So in all, there's another DNS number being used. Not something you can fix by wildly editing XML files.

What you have to try is to get the whole platform to recognize the new server. That can be done by resetting the project (thus losing the units you haven't reported yet) or by waiting until it recognzies the correct DNS (can take a long while) or by trying to uninstall the whole thing off the PC. By uninstalling Boinc you will lose nothing of the units that should still be uploaded, reported or crunched.

Then just reboot the computer to make sure its lost all its cached contents, reinstall Boinc and try again. You may even get there by just rebooting the computer, without uninstalling/reinstalling Boinc.

But don't edit XML files if you're not sure what you're doing.

---

All right i've found the problem. In fact it was a homemade problem. Because i had some dns-problems a long time ago i added an entry to my hosts-file with the old scheduler after removing the entry i got the new ip. And now i've reported all 33 Results. Thanks for your help.

---

BOINC Doc | Team-Site | BOINC-Podcast

The address isn't wrong. The scheduler is on the same physical address of setiboinc.ssl.berkeley.edu .. What has changed is the server that the scheduler lives on. So in all, there's another DNS number being used. Not something you can fix by wildly editing XML files.

I don't recall proposing 'wildly editing' XML files.
But it is a fact that _all_ the parameters and settings that BOINC uses are in the XML files, there are no hidden files, and no hard-coded address settings. If something is wrong in the XML files, they are just text files and can be edited - with reasonable care.

If a URL is for some reason wrong in the XML files, chnage it.
If the URLs are all correct and still not connecting, then it is a network issue - most likely a stale DNS record.

But don't edit XML files if you're not sure what you're doing.

There is nothing magic about the XML files, they're not proprietry or checksummed or anything fancy. URLs are exceptionally easy to spot.

So long as you have a backup of the BOINC folder, I don't see what possible harm you can do.
More 'damage' (read lost units) has been done by copying in optimized science apps and/or/with/without (in)appropriate app_info.xml files.

In any event, if the worst happens, one only has to invoke the ultimate solution - reset/re-install.

---