Kevin,

Not sure if the information you requested was for this thread's problem or for the post regarding 'unexpected XML tag or syntax'. But with regards to the association of PV and not receiving any tasks, this is what my log shows for a similarly affected computer:



Unless I'm mistaken, the same WU that was initially discarded was subsequently sent again a few minutes later. I hope this helps.

I found a work around if you're using an app_info file but you may need to have at least 1 WU of each version in your cache for it to work. That's the way i got it to work.
If you have removed the app_info file from the projects folder use the text below to replace it. Shut down boinc, copy and paste into notepad. This text is for my rigs to run 10 WUs at a time. Make the necessary changes for your rigs accordingly in the
<avg_ncpus>0.80</avg_ncpus>
<max_ncpus>1.0</max_ncpus>
and
<count>.10</count>
area of the code for both apps to what you need for your rigs.
Rename the file app_info.xml, drop it back into the WCG project folder, restart boinc and you should be good to go. I was able to get new 705 tasks after the 656 task had finished. Then some more 656 tasks showed up so it seems to be working. *fingers crossed*

<app_info>
<app>
<name>hcc1</name>
<user_friendly_name>Help Conquer Cancer</user_friendly_name>
</app>
<file_info>
<name>wcg_hcc1_img_7.05_windows_intelx86__ati_hcc1</name>
<executable/>
</file_info>
<file_info>
<name>hcckernel.cl.7.05</name>
<executable/>
</file_info>
<app_version>
<app_name>hcc1</app_name>
<version_num>705</version_num>
<platform>windows_intelx86</platform>
<plan_class>ati_hcc1</plan_class>
<avg_ncpus>0.80</avg_ncpus>
<max_ncpus>1.0</max_ncpus>
<coproc>
<type>ATI</type>
<count>.10</count>
</coproc>
<file_ref>
<file_name>wcg_hcc1_img_7.05_windows_intelx86__ati_hcc1</file_name>
<main_program/>
</file_ref>
<file_ref>
<file_name>hcckernel.cl.7.05</file_name>
<open_name>hcckernel.cl</open_name>
</file_ref>
</app_version>
<app>
<name>hcc1</name>
<user_friendly_name>Help Conquer Cancer</user_friendly_name>
</app>
<file_info>
<name>wcg_hcc1_img_6.56_windows_intelx86__ati_hcc1</name>
<executable/>
</file_info>
<file_info>
<name>hcckernel.cl.6.56</name>
<executable/>
</file_info>
<app_version>
<app_name>hcc1</app_name>
<version_num>656</version_num>
<platform>windows_intelx86</platform>
<plan_class>ati_hcc1</plan_class>
<avg_ncpus>0.80</avg_ncpus>
<max_ncpus>1.0</max_ncpus>
<coproc>
<type>ATI</type>
<count>.10</count>
</coproc>
<file_ref>
<file_name>wcg_hcc1_img_6.56_windows_intelx86__ati_hcc1</file_name>
<main_program/>
</file_ref>
<file_ref>
<file_name>hcckernel.cl.6.56</file_name>
<open_name>hcckernel.cl</open_name>
</file_ref>
</app_version>
</app_info>

So here is the problem:



A job gets assigned that uses the old app version.
The host is anonymous platform, so it ignores the app version sent.
The host can't find app version that matches the platform, version num and plan_class so it discards the job

The problem is that discarding the job does not report to the server that the client isn't running it. Thus the job is still assigned to you.

Next request to the server, you get sent the job again. This continues.

Even worse, each time the job is sent to you the deadline for the job is re-evaluated and possibly slightly increased. Thus it can potentially never pass its deadline.

When I started digging into this problem today, there were a lot of computers who were repeatedly being resent the same jobs.

This issue occurs when all three of app_info.xml is used, homogenous_app_version and resend_results.


Resolving this issue for the long run is going to be somewhat tricky. As a result, what I am doing now is changing the app_version on the workunits to all be at the 705 level. The new binaries are backward compatible so this shouldn't be an issue. This should return life to normal for now.

Here is to normality! We have been missing it.

Lawrence

We are the only ones using homogenous_app_version - and I believe we are the first. And after reviewing the BOINC code today, I've discovered that it has a complete lack of support for the app_info.xml/anonymous mechanism. Additionally, not all projects use the resend lost results feature.

This is why I manually moved the app version numbers up so the part of code that deals with deprecated app versions will no longer be executed.

However, since we are using the homogenous_app_version logic, we still traverse a path of code that other projects aren't using. And it is that code in particular that doesn't check which app/platform/plan_class sent by the client for the anonymous platforms.

We need to use this feature because the nvidia results don't match the ati results and this is the only mechanism available to separate the results into different buckets.

We are going to have to modify this section of so that it works correctly.

And just to be clear - the code we are talking about is standard stock BOINC code. It can be found here:

http://boinc.berkeley.edu/trac/browser/boinc/sched/sched_resend.cpp#L155
http://boinc.berkeley.edu/trac/browser/boinc/sched/sched_version.cpp#L536
http://boinc.berkeley.edu/trac/browser/boinc/sched/sched_version.cpp#L420