Difference between revisions of "How to post with full details on what your connection does?"

Revision as of 20:51, 4 June 2016

When you're seeing predominantly the below error messages, there are things you can check if it's on your side, or the project's side.

• 2/6/2008 11:13:32 AM||Project communication failed: attempting access to reference site
• 2/6/2008 11:13:33 AM||Access to reference site succeeded - project servers may be temporarily down.
• 2/6/2008 11:13:35 AM|Project-name@home|Scheduler request failed: Timeout was reached

First of all check if the project's servers are online. Most projects have a Server status link on their front page. Check through there if the project isn't down for backup or other maintenance.

If the project is up, go do the next thing.

Try to ping the project. To do this, you need the project's address and the command line.

• Go to Start->Run and type cmd, then click OK.
• In the window that opens, type ping project URL, where the URL is without the http:// part. Example given:

ping setiathome.berkeley.edu

Now press Enter.

Your computer will ping the project computer 4 times and listen for the returns, showing you how long it takes for the pings to return. If you can ping without any packet losses, then that's good.

In the same command window, try a trace route to the project server. Again you need the project URL without the http:// part. Type in tracert project URL, example given:

tracert setiathome.berkeley.edu 

and hit Enter.

This will trace the route your signal is taking across the internet to the project server.

If there are any time outs along the way, then that's not good. Those servers are down, or have other trouble. Check if your signal reaches the project server.

To be able to use any of these traces in a post, you can also let them go to a text file.

• To do so, type for ping: ping project URL > C:\ping.txt

• For tracert type: tracert project URL > C:\ racert.txt

You can post that info in a post on the project forums when you ask for help.

We'll now check what BOINC is doing, through some debugging flags in the core client configuration file, cc_config.xml

Check this FAQ on how to set up the cc_config.xml file.

Add to it:

<cc_config>
<log_flags>
    <task>1</task>
    <file_xfer>1</file_xfer>
    <sched_ops>1</sched_ops> 
    <file_xfer_debug>1</file_xfer_debug>
    <http_debug>1</http_debug>
    <http_xfer_debug>1</http_xfer_debug> 
    <network_status_debug>1</network_status_debug>
</log_flags>
</cc_config>

The first 3 are always in cc_config.xml, they'll always need to be on.

• With the file_xfer_debug flag we'll track any files you upload or download.

• With the http_debug flag we'll debug general http operations.

• With the http_xfer_debug flag we'll check your network operations.

While with the network_status_debug flag we'll check if you can make contact to the outside world.

The best thing to do before you activate this cc_config.xml is exit BOINC, navigate to your BOINC directory and rename your stdoutdae.txt file to stdoutdae.old. When BOINC restarts it'll read the cc_config.xml file and make a new stdoutdae.txt file all by itself, immediately logging everything we need.

Run BOINC. Update on the project you have problems with.

Let BOINC run for a while, through at least one time out on the scheduler.

If you now make a post on the forums, you can add to it:

• What your ping does. Post the contents of ping.txt
• What your tracert does. Post the contents of tracert.txt
• What BOINC does. Post the contents of stdoutdae.txt while it went through one scheduler refusal.

| Jorden
| 9
| 1
| 18:36:11
| 2008-02-11
| 170000
| 1
| 299
| 2008-02-11 18:36:11
| 2008-02-11 18:36:11

|-