Wonder how many of those 4.6 million results out in the field will hit the upload server when it comes back online?

Results ready to send				158,484		21,179
Results out in the field			4,618,405	72,475
Results returned and awaiting validation	6,473,085	75,090
Workunits waiting for validation		0		0
Workunits waiting for assimilation		947,649		5,141
Workunit files waiting for deletion		46		0
Result files waiting for deletion		140		0
Workunits waiting for db purging		937,110		21
Results waiting for db purging			1,981,623	914

Results ready to send				161,415		22,761
Results out in the field			4,615,486	72,475
Results returned and awaiting validation	6,385,568	75,090
Workunits waiting for validation		0		0
Workunits waiting for assimilation		903,271		5,141
Workunit files waiting for deletion		11		0
Result files waiting for deletion		98		0
Workunits waiting for db purging		981,631		21
Results waiting for db purging			2,072,158	914

In addition I am now seeing weird stuff in the error logs that makes no sense??

17/06/2010 08:30:00 SETI@home Beta Test You used the wrong URL for this project
17/06/2010 08:30:00 SETI@home Beta Test The correct URL is http://setiweb.ssl.berkeley.edu/beta/

<app_name>setiathome_enhanced</app_name> Im guessing that this is where the error is

<version_num>610</version_num>
<plan_class>cuda</plan_class>

As addition to Claggy's message: Dennis, saw you scheduling values for this projects?

The collatz scheduling priority is roughly double that of seti, can that be changed?

boinccmd --set_debts setiathome.berkeley.edu 0 0 boinc.thesonntags.com/collatz 0 0

ok. will look at these again. I have allowed the BF to try a scan with a different program, I can't remember what it is, I will check this too.

___________
WBW, Leonid

PING setiboincdata.ssl.berkeley.edu (208.68.240.16) 56(84) bytes of data.
64 bytes from setiboincdata.ssl.berkeley.edu (208.68.240.16): icmp_seq=1 ttl=53 time=343 ms

telnet: connect to address 208.68.240.16: Connection refused

but I'm trying to install a new version of boinc (boinc_6.10.44_i686-pc-linux-gnu.sh) on a Fedora Core 12 machine.

The 210 tasks dahls has are "Ready to report" so they have already been uploaded successfully. Communications with the upload handler are done, it's communicating with the Scheduler that's failing.

<scheduler_reply>
<scheduler_version>611</scheduler_version>
<master_url>http://setiathome.berkeley.edu/</master_url>
<request_delay>11.000000</request_delay>
<message priority="low">Error in request message: no start tag </message>
<project_name>SETI@home</project_name>
</scheduler_reply>

In my opinion it seems like there is something wrong at the server side.

...
<result_ack>
    <name>11dc06ag.26523.16023.4.10.112_0</name>
</result_ack>
...

Should I delete everything on the triple core machine and then reinstall BOINC again?

The triple core machine has probably not been able to get new work sets for at least a week. And it has 210 work sets to report, but it's not able to report them.

<data_server_reply>
    <status>1</status>
    <message>no command</message>
</data_server_reply>

An explanation of why this is happened would be nice :)

This is curious. If I click on my own link (which worked yesterday), I get "The service is unavailable".

But if I click on the copy of the exact same link which I posted in the Beta forum a few minutes later, the app downloads OK.

(btw, is any reason to double mention of all files in heading section? I mean why each file_ref should have corresponding file_info? )

• files specified at <file_info> sections (right after the <app>) are declarations of all files which can be needed by any versions of specified app (i.e. for file existance check);
  
• and files, mentioned at <file_ref> sections of one <app_version> - as files which must be copied to corresponding slot along with workunit file and chosen version of app for future processing.
  

I have updated to the same version that Leopaldo is using
...

But not if you intend to run AQUA's multi-thread CPU applications. Unfinished business.

Querry by HostID failed...........
Querry by UserID failed...........

When the querry is by User ID the waiting period is 0.50 and fails.