Still having some issues getting any work.

Running Boinc ver. 6.12.34 (x64)

-----------------------------------------------------------------------------
10/13/2011 6:32:15 PM | SETI@home | update requested by user
10/13/2011 6:32:17 PM | SETI@home | Sending scheduler request: Requested by user.
10/13/2011 6:32:17 PM | SETI@home | Requesting new tasks for CPU and NVIDIA GPU
10/13/2011 6:32:39 PM | SETI@home | Scheduler request failed: Couldn't connect to server
10/13/2011 6:32:53 PM | | Project communication failed: attempting access to reference site
10/13/2011 6:32:55 PM | | Internet access OK - project servers may be temporarily down.
------------------------------------------------------------------------------

I have a 2nd comp next to me and it gets work units.

Suggestions??

Thanks,
-W

---

What happens when you ping 208.68.240.13 or 208.68.240.16 or 208.68.240.18 or 208.68.240.20 ???

From the computer that is having problems.

---

Dave

What happens when you ping 208.68.240.13 or 208.68.240.16 or 208.68.240.18 or 208.68.240.20 ???

From the computer that is having problems.

I ping'd all 3 and all request timed out.

thanks,
-W

---

Your Seti messages indicate that internet access is ok.

Try to ping 64.183.64.218. If that is successful, I would try a reboot (to clear cached info) and see what happens.

It is not logical that 2 machines, with the same internet access, would be subject to the HE connection issue (see thread above, HE connection problems).

You might also try those pings from the good machine, for reference.

---

Dave

If the requests time out it's in all likelyhood the HE link.
No it doesn't make sense that of two machines on the same link only one gets through.

Check the 'temporary fix' thread on proxy use and this post from Richard on how to tell BOINC to use a proxy.

Just another tip, its been noticed at times that DNS problems occurs when the flakey router decides to change who connects and who doesn't so do a "ipconfig /flushdns" as this will help during those times.

Cheers.

---

Just another tip, its been noticed at times that DNS problems occurs when the flakey router decides to change who connects and who doesn't so do a "ipconfig /flushdns" as this will help during those times.

Cheers.

Yes, I'd second the point about DNS problems - either when the flakey router flips, sometimes when round robin DNS flips the active download server, and sometimes both together.....

What you do about it depends on how you connect to the internet. Try doing

ipconfig /displaydns

first to see what's in your computer's DNS cache: all the SETI stuff has a very short TTL (time to live) - uploads and downloads five minutes, scheduler one minute, according to one that's just going through now - so the chances are you'll see nothing related to SETI in there. So flushing that (empty) cache isn't going to do any good: what you have to do is flush the next DNS cache up the line.

In my case, with a small home network, the next link in my DNS chain is my home router - one of the ubiquitous 'DSL plus four LAN ports' type. That is set as the DNS server for my LAN, and in turn picks up the DNS servers specified by my ISP (I could set them manually, but I haven't).

When DNS packs up on me (which it did a lot around the time of the DDOS attacks two weeks ago), I find that rebooting my home router has the highest chance of fixing things. That's in the configuration described above: YMMV, and there's no substitute for learning how your own internet connection works, and applying restart techniques which are appropriate to your own network environment.

Just another tip, its been noticed at times that DNS problems occurs when the flakey router decides to change who connects and who doesn't so do a "ipconfig /flushdns" as this will help during those times.

Cheers.

Yes, I'd second the point about DNS problems - either when the flakey router flips, sometimes when round robin DNS flips the active download server, and sometimes both together.....

What you do about it depends on how you connect to the internet. Try doing

ipconfig /displaydns

first to see what's in your computer's DNS cache: all the SETI stuff has a very short TTL (time to live) - uploads and downloads five minutes, scheduler one minute, according to one that's just going through now - so the chances are you'll see nothing related to SETI in there. So flushing that (empty) cache isn't going to do any good: what you have to do is flush the next DNS cache up the line.

In my case, with a small home network, the next link in my DNS chain is my home router - one of the ubiquitous 'DSL plus four LAN ports' type. That is set as the DNS server for my LAN, and in turn picks up the DNS servers specified by my ISP (I could set them manually, but I haven't).

When DNS packs up on me (which it did a lot around the time of the DDOS attacks two weeks ago), I find that rebooting my home router has the highest chance of fixing things. That's in the configuration described above: YMMV, and there's no substitute for learning how your own internet connection works, and applying restart techniques which are appropriate to your own network environment.

Are you suggesting that I try turning off the router/modem and then turning it back on?
I too have not gotten any new SETI work units for a long long time - over a month by the graph in BOINC. Yet Einstein and MilkyWay are happily getting and reporting completed work units

---

It may very well help.

---

Dave

What happens when you ping 208.68.240.13 or 208.68.240.16 or 208.68.240.18 or 208.68.240.20 ???

From the computer that is having problems.

I pinged all four of those as well and got request timeouts for each of them :|

---

Just another tip, its been noticed at times that DNS problems occurs when the flakey router decides to change who connects and who doesn't so do a "ipconfig /flushdns" as this will help during those times.

Cheers.

Yes, I'd second the point about DNS problems - either when the flakey router flips, sometimes when round robin DNS flips the active download server, and sometimes both together.....

What you do about it depends on how you connect to the internet. Try doing

ipconfig /displaydns

first to see what's in your computer's DNS cache: all the SETI stuff has a very short TTL (time to live) - uploads and downloads five minutes, scheduler one minute, according to one that's just going through now - so the chances are you'll see nothing related to SETI in there. So flushing that (empty) cache isn't going to do any good: what you have to do is flush the next DNS cache up the line.

In my case, with a small home network, the next link in my DNS chain is my home router - one of the ubiquitous 'DSL plus four LAN ports' type. That is set as the DNS server for my LAN, and in turn picks up the DNS servers specified by my ISP (I could set them manually, but I haven't).

When DNS packs up on me (which it did a lot around the time of the DDOS attacks two weeks ago), I find that rebooting my home router has the highest chance of fixing things. That's in the configuration described above: YMMV, and there's no substitute for learning how your own internet connection works, and applying restart techniques which are appropriate to your own network environment.

Are you suggesting that I try turning off the router/modem and then turning it back on?
I too have not gotten any new SETI work units for a long long time - over a month by the graph in BOINC. Yet Einstein and MilkyWay are happily getting and reporting completed work units

Or just type in ipconfig /flushdns into Run command or Command Line box. ;)

Cheers

---

I have not been able to connect uploads, downloads, updates, for a few days. Turned off my modem, waited a ten count and turned it back on. Everything is connecting now with decent transfer speed. I wish it was this easy all the time

CL

---

Just another tip, its been noticed at times that DNS problems occurs when the flakey router decides to change who connects and who doesn't so do a "ipconfig /flushdns" as this will help during those times.

Cheers.

Yes, I'd second the point about DNS problems - either when the flakey router flips, sometimes when round robin DNS flips the active download server, and sometimes both together.....

What you do about it depends on how you connect to the internet. Try doing

ipconfig /displaydns

first to see what's in your computer's DNS cache: all the SETI stuff has a very short TTL (time to live) - uploads and downloads five minutes, scheduler one minute, according to one that's just going through now - so the chances are you'll see nothing related to SETI in there. So flushing that (empty) cache isn't going to do any good: what you have to do is flush the next DNS cache up the line.

In my case, with a small home network, the next link in my DNS chain is my home router - one of the ubiquitous 'DSL plus four LAN ports' type. That is set as the DNS server for my LAN, and in turn picks up the DNS servers specified by my ISP (I could set them manually, but I haven't).

When DNS packs up on me (which it did a lot around the time of the DDOS attacks two weeks ago), I find that rebooting my home router has the highest chance of fixing things. That's in the configuration described above: YMMV, and there's no substitute for learning how your own internet connection works, and applying restart techniques which are appropriate to your own network environment.

Are you suggesting that I try turning off the router/modem and then turning it back on?
I too have not gotten any new SETI work units for a long long time - over a month by the graph in BOINC. Yet Einstein and MilkyWay are happily getting and reporting completed work units

Or just type in ipconfig /flushdns into Run command or Command Line box. ;)

Cheers

I just did that.
Still no joy D:

---

If you timeout on the server ping/tracert and resetting router/DNS doesn't help, it's time to look for a proxy...

If you timeout on the server ping/tracert and resetting router/DNS doesn't help, it's time to look for a proxy...

Do MilkyWay@Home and Einstein@Home utilize some other method or domain for connection? Because as I said, they connect fine - I report and get new work from them regularly. It is only SETI that seems to have the connection issue :|

---

If you timeout on the server ping/tracert and resetting router/DNS doesn't help, it's time to look for a proxy...

Do MilkyWay@Home and Einstein@Home utilize some other method or domain for connection? Because as I said, they connect fine - I report and get new work from them regularly. It is only SETI that seems to have the connection issue :|

There must be a lot of different MODEM/ROUTERS, as I was able to
'open'/access the router and change settings, even speed. It is a device or gataway
and has an IP adress, mine was 192.168.1.1.
Well KPN-Planet found out and gave me a new kind of ROUTER, which handles WWW, Digital Telly and 2 Phone lines.
But can not access it anymore, it runs a embedded *NIX version and proved to
be able to connect 4(or more) hosts, 2 TVs, 2 phones and a WLAN connection to my LT

Never, experienced connection problems, maybe 1 miss, but the next try is always OK.
But shouldn't this be in the ~ Temporary Fix for HE connection problems ~ thread?

---

If you timeout on the server ping/tracert and resetting router/DNS doesn't help, it's time to look for a proxy...

Do MilkyWay@Home and Einstein@Home utilize some other method or domain for connection? Because as I said, they connect fine - I report and get new work from them regularly. It is only SETI that seems to have the connection issue :|

Yes, the problem is one of the last links en route to the SETI servers.
Other projects will not be affected.

Hi All

I did a fresh install of boinc and it still wont add (Seti@home project) to the Boinc manager it doe's not finish the installation and doe's not download the stock Application file, which i think sets up user and account details so boinc can communicate to all the Seti@home servers. (I think thats what it doe's).

I am running 64bit Linux.(I also tried to install Boinc in Windows7 and the same thing happens). All other projects are fine.


Here is the logs:

Wed 19 Oct 2011 08:06:08 AM EST | | Starting BOINC client version 6.12.33 for x86_64-pc-linux-gnu
Wed 19 Oct 2011 08:06:08 AM EST | | Config: GUI RPC allowed from:
Wed 19 Oct 2011 08:06:08 AM EST | | log flags: file_xfer, sched_ops, task
Wed 19 Oct 2011 08:06:08 AM EST | | Libraries: libcurl/7.21.6 OpenSSL/1.0.0e zlib/1.2.3.4 libidn/1.22 librtmp/2.3
Wed 19 Oct 2011 08:06:08 AM EST | | Data directory: /var/lib/boinc-client
Wed 19 Oct 2011 08:06:08 AM EST | | Processor: 6 AuthenticAMD AMD Phenom(tm) II X6 1090T Processor [Family 16 Model 10 Stepping 0]
Wed 19 Oct 2011 08:06:08 AM EST | | Processor: 512.00 KB cache
Wed 19 Oct 2011 08:06:08 AM EST | | Processor features: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni monitor
Wed 19 Oct 2011 08:06:08 AM EST | | OS: Linux: 3.0.0-12-generic
Wed 19 Oct 2011 08:06:08 AM EST | | Memory: 3.62 GB physical, 3.75 GB virtual
Wed 19 Oct 2011 08:06:08 AM EST | | Disk: 194.67 GB total, 130.15 GB free
Wed 19 Oct 2011 08:06:08 AM EST | | Local time is UTC +11 hours
Wed 19 Oct 2011 08:06:08 AM EST | | No usable GPUs found
Wed 19 Oct 2011 08:06:08 AM EST | | A new version of BOINC is available. <a href=http://boinc.berkeley.edu/download.php>Download it.</a>
Wed 19 Oct 2011 08:06:08 AM EST | World Community Grid | URL http://www.worldcommunitygrid.org/; Computer ID 1747131; resource share 100
Wed 19 Oct 2011 08:06:08 AM EST | SETI@home | URL http://setiathome.berkeley.edu/; Computer ID not assigned yet; resource share 100
Wed 19 Oct 2011 08:06:08 AM EST | rosetta@home | URL http://boinc.bakerlab.org/rosetta/; Computer ID 1485307; resource share 100
Wed 19 Oct 2011 08:06:08 AM EST | World Community Grid | General prefs: from World Community Grid (last modified 11-Apr-2011 17:04:20)
Wed 19 Oct 2011 08:06:08 AM EST | World Community Grid | Host location: none
Wed 19 Oct 2011 08:06:08 AM EST | World Community Grid | General prefs: using your defaults
Wed 19 Oct 2011 08:06:08 AM EST | | Reading preferences override file
Wed 19 Oct 2011 08:06:08 AM EST | | Preferences:
Wed 19 Oct 2011 08:06:08 AM EST | | max memory usage when active: 1854.31MB
Wed 19 Oct 2011 08:06:08 AM EST | | max memory usage when idle: 3708.62MB
Wed 19 Oct 2011 08:06:08 AM EST | | max disk usage: 10.00GB
Wed 19 Oct 2011 08:06:08 AM EST | | max CPUs used: 5
Wed 19 Oct 2011 08:06:08 AM EST | | suspend work if non-BOINC CPU load exceeds 50 %
Wed 19 Oct 2011 08:06:08 AM EST | | (to change preferences, visit the web site of an attached project, or select Preferences in the Manager)
Wed 19 Oct 2011 08:06:08 AM EST | | Not using a proxy
Wed 19 Oct 2011 08:06:36 AM EST | World Community Grid | Restarting task DSFL_00000033_0000046_0038_0 using dsfl version 619
Wed 19 Oct 2011 08:06:36 AM EST | World Community Grid | Restarting task DSFL_00000033_0000046_0773_1 using dsfl version 619
Wed 19 Oct 2011 08:06:36 AM EST | World Community Grid | Restarting task c4cw_target04_149771283_0 using c4cw version 641
Wed 19 Oct 2011 08:06:36 AM EST | rosetta@home | Restarting task 3alipa_1_CYCA_1jl1_ProteinInterfaceDesign_26Aug2011_30693_619_0 using minirosetta version 314
Wed 19 Oct 2011 08:06:36 AM EST | rosetta@home | Restarting task place_CwEfDf_20111001_EBOV_GP3_1fm4_ProteinInterfaceDesign_01Oct2011_33650_156_0 using minirosetta version 314
Wed 19 Oct 2011 08:11:39 AM EST | SETI@home | Sending scheduler request: To fetch work.
Wed 19 Oct 2011 08:11:39 AM EST | SETI@home | Requesting new tasks for CPU
Wed 19 Oct 2011 08:13:40 AM EST | | Project communication failed: attempting access to reference site
Wed 19 Oct 2011 08:13:40 AM EST | SETI@home | Scheduler request failed: Timeout was reached
Wed 19 Oct 2011 08:13:42 AM EST | | Internet access OK - project servers may be temporarily down.
Wed 19 Oct 2011 08:15:53 AM EST | rosetta@home | Computation for task 3alipa_1_CYCA_1jl1_ProteinInterfaceDesign_26Aug2011_30693_619_0 finished
Wed 19 Oct 2011 08:15:53 AM EST | rosetta@home | Restarting task ploop2x3_design_12_abinitio_SAVE_ALL_OUT_34364_4381_0 using minirosetta version 314
Wed 19 Oct 2011 08:15:55 AM EST | rosetta@home | Started upload of 3alipa_1_CYCA_1jl1_ProteinInterfaceDesign_26Aug2011_30693_619_0_0
Wed 19 Oct 2011 08:16:00 AM EST | rosetta@home | Finished upload of 3alipa_1_CYCA_1jl1_ProteinInterfaceDesign_26Aug2011_30693_619_0_0
Wed 19 Oct 2011 08:16:02 AM EST | rosetta@home | Sending scheduler request: To report completed tasks.
Wed 19 Oct 2011 08:16:02 AM EST | rosetta@home | Reporting 1 completed tasks, not requesting new tasks
Wed 19 Oct 2011 08:16:04 AM EST | rosetta@home | Scheduler request completed
Wed 19 Oct 2011 08:54:37 AM EST | SETI@home | Sending scheduler request: To fetch work.
Wed 19 Oct 2011 08:54:37 AM EST | SETI@home | Requesting new tasks for CPU
Wed 19 Oct 2011 08:56:16 AM EST | World Community Grid | Computation for task DSFL_00000033_0000046_0773_1 finished
Wed 19 Oct 2011 08:56:16 AM EST | rosetta@home | Starting task 3filtr5A_CYpa_2avk_ProteinInterfaceDesign_23Aug2011_30588_623_0 using minirosetta version 314
Wed 19 Oct 2011 08:56:18 AM EST | World Community Grid | Started upload of DSFL_00000033_0000046_0773_1_0
Wed 19 Oct 2011 08:56:26 AM EST | World Community Grid | Finished upload of DSFL_00000033_0000046_0773_1_0
Wed 19 Oct 2011 08:56:38 AM EST | | Project communication failed: attempting access to reference site
Wed 19 Oct 2011 08:56:38 AM EST | SETI@home | Scheduler request failed: Timeout was reached
Wed 19 Oct 2011 08:56:40 AM EST | | Internet access OK - project servers may be temporarily down.
Wed 19 Oct 2011 08:56:43 AM EST | World Community Grid | Sending scheduler request: To report completed tasks.
Wed 19 Oct 2011 08:56:43 AM EST | World Community Grid | Reporting 1 completed tasks, not requesting new tasks
Wed 19 Oct 2011 08:56:46 AM EST | World Community Grid | Scheduler request completed
Wed 19 Oct 2011 09:03:45 AM EST | World Community Grid | Computation for task DSFL_00000033_0000046_0038_0 finished
Wed 19 Oct 2011 09:03:45 AM EST | World Community Grid | Starting task oy162_00014_10 using hpf2 version 640
Wed 19 Oct 2011 09:03:48 AM EST | World Community Grid | Started upload of DSFL_00000033_0000046_0038_0_0
Wed 19 Oct 2011 09:03:54 AM EST | World Community Grid | Finished upload of DSFL_00000033_0000046_0038_0_0
Wed 19 Oct 2011 09:03:58 AM EST | World Community Grid | Sending scheduler request: To report completed tasks.
Wed 19 Oct 2011 09:03:58 AM EST | World Community Grid | Reporting 1 completed tasks, not requesting new tasks
Wed 19 Oct 2011 09:04:00 AM EST | World Community Grid | Scheduler request completed
Wed 19 Oct 2011 09:23:45 AM EST | rosetta@home | Computation for task place_CwEfDf_20111001_EBOV_GP3_1fm4_ProteinInterfaceDesign_01Oct2011_33650_156_0 finished
Wed 19 Oct 2011 09:23:45 AM EST | rosetta@home | Starting task Aug20_needle_15start_test_SAVE_ALL_OUT__31513_99967_0 using minirosetta version 314
Wed 19 Oct 2011 09:23:47 AM EST | rosetta@home | Started upload of place_CwEfDf_20111001_EBOV_GP3_1fm4_ProteinInterfaceDesign_01Oct2011_33650_156_0_0
Wed 19 Oct 2011 09:23:53 AM EST | rosetta@home | Finished upload of place_CwEfDf_20111001_EBOV_GP3_1fm4_ProteinInterfaceDesign_01Oct2011_33650_156_0_0
Wed 19 Oct 2011 09:23:54 AM EST | rosetta@home | Sending scheduler request: To report completed tasks.
Wed 19 Oct 2011 09:23:54 AM EST | rosetta@home | Reporting 1 completed tasks, not requesting new tasks
Wed 19 Oct 2011 09:23:57 AM EST | rosetta@home | Scheduler request completed
Wed 19 Oct 2011 09:40:31 AM EST | World Community Grid | Computation for task c4cw_target04_149771283_0 finished
Wed 19 Oct 2011 09:40:31 AM EST | World Community Grid | Starting task X0910056300778200509222324_1 using hcc1 version 640
Wed 19 Oct 2011 09:40:33 AM EST | World Community Grid | Started upload of c4cw_target04_149771283_0_0
Wed 19 Oct 2011 09:40:40 AM EST | World Community Grid | Finished upload of c4cw_target04_149771283_0_0
Wed 19 Oct 2011 09:40:40 AM EST | World Community Grid | Sending scheduler request: To report completed tasks.
Wed 19 Oct 2011 09:40:40 AM EST | World Community Grid | Reporting 1 completed tasks, not requesting new tasks
Wed 19 Oct 2011 09:40:43 AM EST | World Community Grid | Scheduler request completed

I have noticed Some people are not affected and have been getting work units.

nick

---

If you timeout on the server ping/tracert and resetting router/DNS doesn't help, it's time to look for a proxy...

I heard using a free proxy server can be dangerous as they can look through your Internet traffic and steel your accounts and passwords etc.

Who can you trust.?

Nick

---

If you timeout on the server ping/tracert and resetting router/DNS doesn't help, it's time to look for a proxy...

Do MilkyWay@Home and Einstein@Home utilize some other method or domain for connection? Because as I said, they connect fine - I report and get new work from them regularly. It is only SETI that seems to have the connection issue :|

Every BOINC project can be anywhere on Earth (so is using absolutely different and independent servers/connection).

e.g.:


Host: setiathome.berkeley.edu
IP: 128.32.18.150
Country: UNITED STATES
Region: CALIFORNIA
City: BERKELEY


Host: einstein.phys.uwm.edu
IP: 129.89.61.70
Country: UNITED STATES
Region: WISCONSIN
City: MILWAUKEE


Host: milkyway.cs.rpi.edu
IP: 128.213.23.40
Country: UNITED STATES
Region: NEW YORK
City: TROY


(Info is from "Flag Button" Opera extension
https://addons.opera.com/en/addons/extensions/details/flag-button/

Which in turn uses this site to get the info (IP Geolocation Data):
http://ipinfodb.com/
)

---

 


- ALF - "Find out what you don't do well ..... then don't do it!" :)