That's weird. Do you have the file in right place? Mistyped the tag name?

Yes, the cc_config.xml already existed and I just added the line. Copy and paste from the web page even. Double checked everything and it looks ok. I know I have to tell boinc to reread the file when I change it. I've been trying to catch the sched_request and sched_reply files (they change on every request) and it seems to be asking for the 64 bit version. I may have to wait as it already had a couple of hours worth of work before I added the line you suggested. Perhaps only the most recent downloads will use the 64 bit.

Then again, as Richard suggested, the project severely underestimated the run time of tasks a while ago and that made the 64 bit app that I was using at the time look very slow, so maybe the project thinks it knows better.

Charlie

Something might be working here. On the application details for the host page

http://findah.ucd.ie/host_app_versions.php?hostid=35108

I see the number of tasks sent as 64 bit work (number of tasks today) increasing as it sends new work. I think once those make it to the top of the queue, it might start using the 64 bit executable although it has not yet downloaded it.

I got impatient and reset the project. It then downloaded the 64 bit executable and new tasks and is using the 64 bit executable on them. I still have the no_alt_platform in the cc_config file. I may play around with it a bit later to see what happens.

Charlie

Just curious, how do you recognize 64 bit or 32 bit work units?

(My experience is limited, until now thought there were no specific bit size build work units. Maybe there is, models that were created to cater for 32-bit OS constraints and bigger ones for 64 bit OSses. At any rate I'd think it novel to get full WUs for a platform and the app not being downloaded until actually one is started. E.g. suppose the project is down, what then?)

Edit: At WCG there's CleanEnergy only available in 32 bit. Applying the no_alt_platform on a 64 bit system does stop this project from even being downloaded... you get a no work for xyz. Similar if certain 32 bit libraries are missing [but this seems to be an exclusive issue to Linux]

---

Coelum Non Animum Mutant, Qui Trans Mare Currunt

The workunits are the same for 32 or 64 bit. They're just data. It's whatever executable is used to process them.

(My experience is limited, until now thought there were no specific bit size build work units. Maybe there is, models that were created to cater for 32-bit OS constraints and bigger ones for 64 bit OSses. At any rate I'd think it novel to get full WUs for a platform and the app not being downloaded until actually one is started. E.g. suppose the project is down, what then?)

When tasks are allocated to a volunteer for processing, the formal specification for the task is handed to the client in two xml blobs - <workunit> and <result>.

Between them they specify, among other things,
* Input file(s)
* Output file(s)
* command line parameters
* application to be used (including version number, platform, and perhaps plan_class)

At the same time, the formal specification for any application version to be used will also be handed down to the client. Usually, this will just be a re-statement of information already known by the client - but occasionally, a project will issue a new application, or update the version of an application already in use.

It's that notification of a new app version which will trigger the downloading of new binaries, libraries and whatever. That will happen at the same time as the downloading of any data files needed for the specific task. There's no question of waiting to download any application related files until the task starts: conversely, no task can be considered 'runnable' (and it won't start) until all related application downloads are complete.

Thx for that and confirming. My query got started by this comment by Charles D "...it might start using the 64 bit executable although it has not yet downloaded it."
Emphasis mine.
Yes, the WU is tagged to an app/version at assignment... had not observed differently, but in progs like BOINCTasks it's just giving the app/version, no bit size, neither in properties of BT or the 7.6.3 BOINC Manager. Scarily, see 32 and 64 bit versions with the same major.minor, just the end tag .intel86 or x86_64 telling in the project/slot folder (Thought to have read in the alpha list that the application is now too printed in the task properties?).

---

Coelum Non Animum Mutant, Qui Trans Mare Currunt

Yes, it is, and this is what it looks like:



though personally I prefer the detail in client_state.xml

<workunit>
    <name>vina_391537_86310_Bre</name>
    <app_name>vina</app_name>
    <version_num>102</version_num>
    <rsc_fpops_est>1155463742373.158900</rsc_fpops_est>
    ...

<result>
    <name>vina_391537_86310_Bre_0</name>
    <final_cpu_time>160.337800</final_cpu_time>
    <final_elapsed_time>167.942581</final_elapsed_time>
    <exit_status>0</exit_status>
    <state>5</state>
    <platform>windows_x86_64</platform>
    <version_num>102</version_num>
    ...