Minor update to fix (hopefully all of) the problems with 0.80

Edit:

Another minor update for the regular 32 bit Windows application to 0.84. This is basically the same thing rebuilt so it should work on Windows 2000

Still not getting any WUs with 2 5870s.

6/13/2011 9:48:57 AM Milkyway@home update requested by user
6/13/2011 9:49:02 AM Milkyway@home Sending scheduler request: Requested by user.
6/13/2011 9:49:02 AM Milkyway@home Not reporting or requesting tasks
6/13/2011 9:49:05 AM Milkyway@home Scheduler request completed

---

Thanks, for the arguments in the cmdline it works now.

Still getting errors under Linux and AMD. Is there a new AMD driver version needed?

Task 48434027
	
Name	de_separation_13_3s_free_2_197533_1307973341_0
Workunit	33769726
Created	13 Jun 2011 | 13:55:45 UTC
Sent	13 Jun 2011 | 13:58:26 UTC
Received	13 Jun 2011 | 13:59:48 UTC
Server state	Over
Outcome	Computation error
Client state	Compute error
Exit status	22 (0x16)
Computer ID	278207
Report deadline	25 Jun 2011 | 13:58:26 UTC
Run time	0.00
CPU time	0.00
Validate state	Invalid
Credit	0.00
Application version	MilkyWay@Home v0.82 (ati14)
Stderr output

<core_client_version>6.10.58</core_client_version>
<![CDATA[
<message>
process exited with code 22 (0x16, -234)
</message>
<stderr_txt>
execv: No such file or directory

</stderr_txt>
]]>

Still getting errors under Linux and AMD. Is there a new AMD driver version needed?

Are you using app_info.xml? It looks like the same problem as this http://setiathome.berkeley.edu/forum_thread.php?id=28991#261512 if you want to try that

With this app_info.xml computation runs fine. Thank you!

<app_info>
<app>
<name>milkyway</name>
</app>
<file_info>
<name>milkyway_separation_0.82_windows_intelx86__ati14.exe</name>
<executable/>
</file_info>
<app_version>
<app_name>milkyway</app_name>
<version_num>82</version_num>
<plan_class>ati14</plan_class>
<flops>1.0e11</flops>
<avg_ncpus>0.05</avg_ncpus>
<max_ncpus>1</max_ncpus>
<coproc>
<type>ATI</type>
<count>0.5</count>
</coproc>
<cmdline>--gpu-target-frequency 120</cmdline>
<file_ref>
<file_name>milkyway_separation_0.82_windows_intelx86__ati14.exe</file_name>
<main_program/>
</file_ref>
</app_version>
</app_info>

O.82 running happily as it was with 0.80. Not running a App_info.xml file. Should I be?

---

Don't drink water, that's the stuff that rusts pipes

O.82 running happily as it was with 0.80. Not running a App_info.xml file. Should I be?

It's never necessary. You only really need it for setting command line arguments or excluding one version and things like that. I want actual project preferences to be a 1.0 feature so you won't need this hackery anymore.

Still getting errors under Linux and AMD. Is there a new AMD driver version needed?

I had the same error, I changed my app_info and now it works fine, maybe it will help :

<app_info>
	<app>
		<name>milkyway</name>
		<user_friendly_name>MilkyWay@Home</user_friendly_name>
	</app>
	<file_info>
		<name>milkyway_separation_0.82_x86_64-pc-linux-gnu__ati14</name>
		<executable/>
	</file_info>
	<app_version>
		<app_name>milkyway</app_name>
		<version_num>82</version_num>
		<platform>x86_64-pc-linux-gnu</platform>
    		<avg_ncpus>0.050000</avg_ncpus>
    		<max_ncpus>0.050000</max_ncpus>
    		<flops>2462546503140.106445</flops>
    		<plan_class>ati14</plan_class>
    		<api_version>6.13.0</api_version>
    		<file_ref>
        		<file_name>milkyway_separation_0.82_x86_64-pc-linux-gnu__ati14</file_name>
        		<main_program/>
    		</file_ref>
                <cmdline>--process-priority 0 --gpu-target-frequency 25 --gpu-disable-checkpointing</cmdline>
    		<coproc>
        		<type>ATI</type>
        		<count>1.000000</count>
    		</coproc>
    		<gpu_ram>262144000.000000</gpu_ram>
	</app_version>
</app_info>

O.82 running happily as it was with 0.80. Not running a App_info.xml file. Should I be?

It's never necessary. You only really need it for setting command line arguments or excluding one version and things like that. I want actual project preferences to be a 1.0 feature so you won't need this hackery anymore.

Thanks for the reply matt :-)

---

Don't drink water, that's the stuff that rusts pipes

Still getting errors under Linux and AMD. Is there a new AMD driver version needed?

I had the same error, I changed my app_info and now it works fine, maybe it will help :

Thanks for providing it.

Never needed one of these prior to this big event.

While I really want to avoid it, it will have to wait so I can restart the client. That is unless there is a remote way to restart it with the GPU recognized.

Still getting errors under Linux and AMD. Is there a new AMD driver version needed?

I had the same error, I changed my app_info and now it works fine, maybe it will help :

Thanks for providing it.

Never needed one of these prior to this big event.

While I really want to avoid it, it will have to wait so I can restart the client. That is unless there is a remote way to restart it with the GPU recognized.

You don't need it unless you want to configure something

Still not getting any WUs with 2 5870s.

6/13/2011 9:48:57 AM Milkyway@home update requested by user
6/13/2011 9:49:02 AM Milkyway@home Sending scheduler request: Requested by user.
6/13/2011 9:49:02 AM Milkyway@home Not reporting or requesting tasks
6/13/2011 9:49:05 AM Milkyway@home Scheduler request completed

Had to reset project to get new WUs.


Edit: Still only got new WUs that one time after the reset!

---

Looks like it's working now after 2nd reset.

---

All I get is "Maximum time limit exceeded" with v.82, 64bit ATI on an HD 4770. That's after around 3 minutes.

For my 5850 the estimated iteration time is now 10% too high.
Still seeing like 25% cpu (=1 core) used by system.
Without cmdline params the system is nearly not responsible.
After some testing I settled for frequency 60, polling 16, prio 1.
This way I am loosing 4 - 5% speed but the system is reacting in a reasonable time again and boinc doesn't complain about 'no response' anymore.

Estimated iteration time 177.678315 ms
Target frequency 50.000000 Hz, polling mode 10
Dividing into 8 chunks, initially sleeping for 0 ms
Integration range: { nu_steps = 640, mu_steps = 1600, r_steps = 1400 }
Using 8 chunk(s) with sizes: 192 208 192 208 192 208 192 208
Integration time = 103.704038 s, average per iteration = 162.037559 ms
Integral 0 time = 104.896748 s
Likelihood time = 2.455765 s

Estimated iteration time 177.678315 ms
Target frequency 60.000000 Hz, polling mode 16
Dividing into 10 chunks, initially sleeping for 0 ms
Integration range: { nu_steps = 640, mu_steps = 1600, r_steps = 1400 }
Using 10 chunk(s) with sizes: 160 160 160 160 160 160 160 160 160 160
Integration time = 107.757288 s, average per iteration = 168.370762 ms
Integral 0 time = 108.960545 s
Estimated iteration time 44.419579 ms
Target frequency 60.000000 Hz, polling mode 16
Dividing into 2 chunks, initially sleeping for 0 ms
Integration range: { nu_steps = 640, mu_steps = 400, r_steps = 1400 }
Using 2 chunk(s) with sizes: 192 208
Integration time = 26.706238 s, average per iteration = 41.728497 ms
Integral 1 time = 27.018571 s
Likelihood time = 2.648356 s

Are the chunk sizes calculated as multiples of 16? Another reason for those bold marked switch in chunk sizes over the iteration range?

On my 5850 I get quite different figures for a unit that finished in 151 secs for a credit of 267.

Estimated iteration time 177.678315 ms
Target frequency 30.000000 Hz, polling mode 1
Dividing into 5 chunks, initially sleeping for 0 ms
Integration range: { nu_steps = 640, mu_steps = 1600, r_steps = 1400 }
Using 5 chunk(s) with sizes: 320 320 320 320 320
Integration time = 114.084658 s, average per iteration = 178.257279 ms
Integral 0 time = 116.439591 s
Estimated iteration time 44.419579 ms
Target frequency 30.000000 Hz, polling mode 1
Dividing into 1 chunks, initially sleeping for 0 ms
Integration range: { nu_steps = 640, mu_steps = 400, r_steps = 1400 }
Using 1 chunk(s) with sizes: 400
Integration time = 26.974717 s, average per iteration = 42.147996 ms
Integral 1 time = 27.656005 s
Likelihood time = 4.263107 s
<background_integral> 0.000305098189400 </background_integral>
<stream_integral> 92.475581503480498 1736.224104130000800 204.743588079532510 </stream_integral>
<background_likelihood> -3.063353447558578 </background_likelihood>
<stream_only_likelihood> -5.860476056409310 -4.499105232285583 -3.983033185712674 </stream_only_likelihood>
<search_likelihood> -2.826062644899529 </search_likelihood>
<search_application> milkywayathome_client separation 0.82 Windows x86_64 double CAL++ </search_application>
10:27:29 (4364): called boinc_finish

HD4870, Win 7 64 Bit, Cat 11.5, BOINC 6.12.26, no app_info (yet). No project reset prior to the ap update. Had no problems with 0.62.

Now ps_test all fail at a little below 50% completion with a "14.06.2011 13:56:31 | Milkyway@home | Aborting task ps_test_4_991375_1: exceeded elapsed time limit 115.16 (3958564.39G/34373.05G)". And after failure they're not killed, i.e. they continue to run for some time (10 - 20s). Could be a BOINC thing - don't know, as I never had this with previous versions.
And the time estimates for these WUs were really low, like 0.01s. (would that mean I'd need to do a roject reset?)

de_separation seem to run fine :)
Well, except that they're running in high priority mode.. LOL. I've got 4 of them left, with BOINC estimating less than 10 mins crunching time for them. 8 days deadline, PC running 24/7. Still "high priority". Oh well, got to give it some time I guess.

Edit: CPU time on an i7 2600 is about half of what it used to be - very nice.

Edit2: project reset -> de_separation are not in "high priority" mode any more. Estimated time still 1s (real time ~130s).

Edit3: after finishing 1 WU the estimated time became quite close to the real one. However, the WUs are back in "high priority" mode. WTF?! I wouldn't mind this, but unfortunately it means BOINC won't get any more WUs. Last time it let MW run dry and triggered the backup project instead...

Edit4: I used to run with an app_info and a target frequency of 60 Hz. Now 30 Hz seems to be less sluggish than before and I feel less of a need for manual intervention.

MrS

---

Scanning for our furry friends since Jan 2002

Follow-up: the result duration correction factor in the client_state.xml was at approximately 100, despite the project reset. Manually set it to 1 and got rid of the high priority mode. The de_separation seem fine now, got my 12 WU cache back.

MrS

---

Scanning for our furry friends since Jan 2002

Still the same problem with and without the app_info.xml as well as multiple resets and detaches. Also rebooted the system as well. Rather disappointing that this happens!