Haven't processed anywhere near 100 on CPU. Mine are processing just like a normal BLC VLAR on the CPU mostly. Maybe 30 minutes faster, so instead of 2 hours I've seen a lot process in 90 minutes or so. They process about the same as a GUPPI on the GPU, around 8 minutes or so. Two up on the GPU's.

They process about the same as a GUPPI on the GPU, around 8 minutes or so. Two up on the GPU's.

I run 1 GPU WU at a time, and the current non VLAR Guppies are processing a couple of minutes faster (no less than 2, sometimes almost 4) than the VLAR ones do.

As far as not hearing about it, well, I did bring it up in your original rescheduling thread as being something that anyone working on a rescheduling application should take into consideration.

1. the instance where sometimes GuppiR reports something like:
~ 0 tasks moved to GPU and 0 tasks moved to CPU ~
when there is definately something to move...and in my experience, sometimes hundreds of tasks.

... then at least put into the help file that the message can be expected as normal if there are minimal or no tasks to move.

If the information message can't be removed entirely, then at least put into the help file that the message can be expected as normal if there are minimal or no tasks to move. As of now, it unnecessarily causes alarm to everyone who starts using the apps until they have more experience with them and likely have posted to the forum already why they are seeing the message and then receive the previous response from the authors Et al.

client_state_prev.xml seems to be a live-backup.
It gets overwritten with client_state.xml as soon as a change to
client_state.xml has succesfully been saved.
That way, if the computer crashes while client_state.xml is in the process of being saved, during the next reboot, Boinc will likely restart with client_state_prev.xml if client_state.xml is corrupt.

In 99% of scenarios, it seems to me that client_state.xml and
client_state_prev.xml will always be identical if not for that fraction of a second when Boinc overwrites client_state_prev.xml with client_state.xml

That's wrong information. The client_state.xml file never gets overwritten and always contains more current data than client_state_prev.xml. In close to 0% of scenarios those two will be identical. (Try running a file comparison utility against the two files.)

Each time the file is updated it is written out as client_state_next.xml. Once that file is successfully written and closed, the existing client_state_prev.xml file is deleted, client_state.xml is renamed as client_state_prev.xml and, finally, client_state_next.xml is renamed as client_state.xml.

But I assume that at some point Mr. Kevvy will address this ...

If not, you might try copying client_state_prev.xml, which is another backup, to client_state.xml.

... where client_state_prev.xml is written by the boinc client, presumably as some type of backup also.

S@h AutoTaskSwap v0.2_beta1 is copying several time that file (copy /Y d:\ProgramData\BOINC\client_state.xml .\client_state-backup.xml>nul)
maybe a corruption occurs ?

i think i will restart seti project/resintall boinc after crunshing all workunit in place....

HELLO to all readers of this thread!
I would like to know if people are using these apps to optimise their rig productivity and how satisfied they are with the results.
Can I ask you all to reply if you are using them and note if you are using both or just the one.
Stephen

The last rescheduler 0.51 from Rob and the latest Qopt 0.49 from Jim who is doing a fine job releasing a string of optimized updates it seems daily.

<app_config>
	<app>
		<name>setiathome_v8</name>
		<gpu_versions>
			<gpu_usage>0.25</gpu_usage>
			<cpu_usage>0.25</cpu_usage>
		</gpu_versions>
	</app>
	<app_version>
		<app_name>setiathome_v8</app_name>
		<plan_class>opencl_nvidia_SoG</plan_class>
		<avg_ncpus>1.0</avg_ncpus>
		<ngpus>1.0</ngpus>
		<gpu_versions>
			<gpu_usage>0.50</gpu_usage>
			<cpu_usage>0.50</cpu_usage>
		</gpu_versions>
	</app_version>
</app_config>

<avg_ncpus>1.0</avg_ncpus> 
<ngpus>1.0</ngpus>

Hi Songbird,
. . May I ask what you are running?? Stock? Lunatics? And CUDA or S0G? There are tweaks to release the CPU from the monopolistic grip of SoG if you want to.
. . For the GTX970 if you are running SoG, in the command line file in your BOINC data directory "Projects/Seti@Home" called "mb_cmdline_win_x86_SSE3_OpenCL_NV.txt" (there may be _S0G after the NV if you are running r3500) [you can edit it with a text editor like Notepad] add "-high_prec_timer -use_sleep" you will then find your CPUs are no longer wholly monopolised.
Stephen

I'm running lunatics 0.45 beta for SoG.(MB8_win_x86_SSE3_OpenCL_NV_SoG_r3500.exe). I did the command line thing. CPU dropped significantly. It's better but still nothing like the CUDA apps from before.
Thanks!

Happily my response time is now much faster.

I welcome your reply and hope this time we can come to a conclusion on "micro managing", especially if I'm still not understanding your perspective well.

There won't be any conclusion because you don't consider what you are doing to be micro management, when it would qualify as a text book example.
Just because you automate something doesn't disqualify it from being micro management.

From the Wikipedia,
Micromanagement
In business management, micromanagement is a management style whereby a manager closely observes or controls the work of subordinates or employees.
BOINC allows you to set your desired levels of CPU usage, network activity, resource share etc & then it just gets on with the job.
You find it necessary to shuffle work around, on top of what you have already set the manager to do.
ie a manager (yourself) closely observes or controls the work of subordinates or employees (BOINC).
As I said, a text book example.

I welcome your reply and hope this time we can come to a conclusion on "micro managing", especially if I'm still not understanding your perspective well.

There won't be any conclusion because you don't consider what you are doing to be micro management, when it would qualify as a text book example.
Just because you automate something doesn't disqualify it from being micro management.


From the Wikipedia,
Micromanagement
In business management, micromanagement is a management style whereby a manager closely observes or controls the work of subordinates or employees.
BOINC allows you to set your desired levels of CPU usage, network activity, resource share etc & then it just gets on with the job.
You find it necessary to shuffle work around, on top of what you have already set the manager to do.
ie a manager (yourself) closely observes or controls the work of subordinates or employees (BOINC).
As I said, a text book example.