... we could schedule more than one task from more than one project to run "at the same time" though they would be interleaved ... but this would address Claggy's problem quite well and address my utilization problem as well ... SaH would get slices as needed to run its kernel and when it was done release the GPU for kernels from MW to be run (for example) getting the best use out of a scarce resource ...

<app_info>

	<app>
		<name>milkyway</name>
	</app>

	<file_info>
		<name>astronomy_0.20_x64_SSE3.exe</name>
		<executable/>
	</file_info>

	<file_info>
		<name>astronomy_0.23_ATI_x64.exe</name>
		<executable/>
	</file_info>

	<file_info>
		<name>brook64.dll</name>
		<executable/>
	</file_info>

	<app_version>
		<app_name>milkyway</app_name>
		<version_num>20</version_num>
		<avg_ncpus>1</avg_ncpus>
		<max_ncpus>1</max_ncpus>
		<platform>windows_x86_64</platform>
		<file_ref>
			<file_name>astronomy_0.20_x64_SSE3.exe</file_name>
			<main_program/>
		</file_ref>
	</app_version>

	<app_version>
		<app_name>milkyway</app_name>
		<version_num>21</version_num>
		<flops>1.0e11</flops>
		<avg_ncpus>0.05</avg_ncpus>
		<max_ncpus>0.5</max_ncpus>
		<platform>windows_x86_64</platform>
		<plan_class>ati13ati</plan_class>
		<coproc>
			<type>ATI</type>
			<count>0.48</count>
		</coproc>
		<cmdline>b-1</cmdline>
		<file_ref>
			<file_name>astronomy_0.23_ATI_x64.exe</file_name>
			<main_program/>
		</file_ref>
		<file_ref>
			<file_name>brook64.dll</file_name>
		</file_ref>
	</app_version>

</app_info>

One Question more maybe.

Why can't we make crunching the CPU AND the GPU (ATI) in the same time for MW ?



JMG

That, and a required hash check for all apps. It shouldn't be hard to get a new hash for one of Cluster Physik's apps verified and accepted when they need to be updated, and this would at least make it more difficult to use unsanctioned code. Of course, hash checks -can- be spoofed, but hopefully no one is that dedicated to messing up the project.

Hash checks don't work here since he's using the anonymous platform. The only way i see to prevent this is to implement the double precision check for anonymous platform (planclass cuda23) too, like it's done for the stock cuda app.

I know I need to use the count tag, but I can't find which file this would go in. Any help would be appreciated.

VJG

<app_info>

	<app>
		<name>milkyway</name>
	</app>

	<file_info>
		<name>astronomy_0.20_x64_SSE3.exe</name>
		<executable/>
	</file_info>

	<file_info>
		<name>astronomy_0.20b_ATI_x64_ati.exe</name>
		<executable/>
	</file_info>

	<file_info>
		<name>brook64.dll</name>
		<executable/>
	</file_info>

	<app_version>
		<app_name>milkyway</app_name>
		<version_num>20</version_num>
		<avg_ncpus>1</avg_ncpus>
		<max_ncpus>1</max_ncpus>
		<platform>windows_x86_64</platform>
		<file_ref>
			<file_name>astronomy_0.20_x64_SSE3.exe</file_name>
			<main_program/>
		</file_ref>
	</app_version>

	<app_version>
		<app_name>milkyway</app_name>
		<version_num>21</version_num>
		<flops>1.0e11</flops>
		<avg_ncpus>0.05</avg_ncpus>
		<max_ncpus>0.5</max_ncpus>
		<platform>windows_x86_64</platform>
		<plan_class>ati13ati</plan_class>
		<coproc>
			<type>ATI</type>
			<count>0.48</count>
		</coproc>
		<cmdline>b-1</cmdline>
		<file_ref>
			<file_name>astronomy_0.20b_ATI_x64_ati.exe</file_name>
			<main_program/>
		</file_ref>
		<file_ref>
			<file_name>brook64.dll</file_name>
		</file_ref>
	</app_version>

</app_info>

...
Any more it does not matter if you crunch 1 or 2 at a time, they take an identical time.

1 at a time: 5:06
2 at a time: 10:12

No benefit at all.

You can do it if you do not use the "optimized apps"

The ATI app is the exact same app as what is in the optimized app package.

So why is the app at 0.38 cpu's and taking about 25 seconds longer on my 4870?

Did you use the b-1 tag in your app_info?

I am back to using a app_info as I did not like that slower crunching, of course I also had to change my prefs to use CPU as it will not get any work when it asks for GPU tasks.

Hi,

Computer has no work, it is only for Milkyway@home, CPU.
It is waiting for more than 18 hours now for work.

The server seems to be sending out work... Is anyone else having this problem?

>eyes, sticks
Reminds me of a [home-made] safety notice I saw in a lab the other day -

"Do not look into the laser with your remaining eye."

However I still claim, that there were WUs that ran 1.5x longer than others with the same credit grants, but will never be able to prove it.

Such a defeatist attitude... ;-)

I have 3 reported tasks from my Pentium 4 right now. One took around 7250 seconds, while the other two took around 5100 seconds, all three getting 53.45 credits.

My average credit per day on that system when I stopped processing here a few days ago was around 800.

7250 + (5100 * 2) = 17450 total runtime seconds thus far.

24 * 60 * 60 = 86400 seconds in a day

86400 / 17450 = 4.9513

53.45 * 3 * 4.9513 = 793.94 ~= "around 800"

Yes, it may "stink" to get multiple of the longer running tasks, but there are also plenty of the shorter running tasks to average things out over the long term.

And just some small suggestion, before I drop this topic completely. It wouldn't hurt if Travis told us not only that there was increase in runtime, but also by how much, and which WUs would that be.

Personally, I think he just meant that they were starting up 3s (3-stream) searches instead of 1 or 2 stream which generally cause the server to be real sluggish. The runtime variation in the tasks has been there for weeks, if not months, so this is a tempest in a teapot...

Also, I must admit, that I have overreacted a bit in my previous posts, as I discovered, that for some unknown reason, my ATIs were running a bit (around 20%) slower from 10am UTC till now (I noticed, that my Collatz tasks took 20% longer to complete). However, considering this the new WUs are still some 1.6 times longer than before, but grant the same credit, which still stinks.

The newer Collatz tasks grant proportional credit at least those that I have checked. There are still some older tasks laying about so you may get a mix of old 500 something and newer 700 something tasks ...

But I fail to understand that eye poking thing you wrote at the end of your post.

Well, having a few slow to medium GPUs working for me is a lot more fun that the alternatives I was suggesting ... then again, maybe some out there enjoy poking their eyes with sticks ... :)