I am using both apps and am very satisfied. 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.

. . Hi Keith,

. . Jim is indeed doing a fine job.

. . Thanks for the reply.

Stephen

.

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.

Since I made the v0.2 frontend to Mr Kevvy's GUPPI Rescheduler for Windows,
I'm very pleased to see my productivity increased by ~15% on my two rigs.
I'm surprised that there isn't more interest.
All have reported an increase of at least 10%, and some almost close to 20%.
I don't even think Lunatics can report such an increase (but it's been so long that I've used stock that I may be wrong).
If it wasn't for Mr Kevvy's app, I would have needed to figure out another way to transfer tasks and it wouldn't have been as simple, efficient and effective.
So thanks Mr Kevvy for the great app and thanks to Jim for taking over my frontend for Windows 7 to 10.

Maybe we should start a new thread after Jim releases his v1.0 (as a totally revamped and much improved version of my v0.2).

If there is more interest, I might put much more work in my proof-of-concept currently called: S@h-MicroMgr
It would bundle any S@h scripts, app and progs (that the creators allow me to bundle) in one Zip file to be extracted directly to the desktop.
The intent is to make it easy for those who don't feel comfortable with the Windows Command Prompt (formely known as MS-DOS).
If anyone is interested in taking a look at my proof-of-concept, aka S@h-McroMgr_v0.1alpha1
please send me a PM and I'll provide you a dropBox link.

Cheers,
RobG

---

I am using both apps and am very satisfied. 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.

. . Hi Keith,

. . Jim is indeed doing a fine job.

. . Thanks for the reply.

Stephen

.

GUPPIRescheduler 0.51 is from Mr. Kevvy, btw.
Do appreciate the kudos, though :)

---

Of course, I misspoke. But with Stubbles the former cheerleader for Mr. Kevvy's app, I got confused. Kudos to all involved with developing the app and front-ends. They have certainly made it easier to optimise the output of the current Lunatics apps with the current task mix from SETI.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

hello I try Kevvy's GUPPI rescheduler program and first time it work well
then i try S@h AutoTaskSwap v0.2_beta1.cmd
because i didn't install boinc on C: i replace in this script
c:\ProgramData\BOINC\ with d:\ProgramData\BOINC\ on all lines
it seems to work well except i had to restart boinc manualy

but I get folowing error:

D:\>cd D:\ProgramData\BOINC
D:\ProgramData\BOINC>GUPPIRescheduler
Mr. Kevvy's GUPPI Rescheduler v0.4 - (c)2016 Kevin Dorner
Reading configuration files...
Error: could not determine CPU version_num from client_state. Nothing changed.

in D:\ProgramData\BOINC\client_state.xml CPU infos are:

<host_cpid>b9c18f2db8229ec97fb461192cb143c0</host_cpid>
<p_ncpus>4</p_ncpus>
<p_vendor>GenuineIntel</p_vendor>
<p_model> Intel(R) Core(TM) i5-3570K CPU @ 3.40GHz [Family 6 Model 58 Stepping 9]</p_model>
<p_features>fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss htt tm pni ssse3 cx16 sse4_1 sse4_2 popcnt aes f16c rdrandsyscall nx lm avx vmx tm2 pbe fsgsbase smep</p_features>

<os_name>Microsoft Windows 10</os_name>
<os_version>Professional x64 Edition, (10.00.10586.00)</os_version>
-<coprocs>
-<coproc_cuda>
<count>2</count>
<name>GeForce GTX 1060 3GB</name>
<available_ram>2651740569.000000</available_ram>

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....
any suggestion is wellcome...

---

... I get folowing error:

D:\>cd D:\ProgramData\BOINC
D:\ProgramData\BOINC>GUPPIRescheduler
Mr. Kevvy's GUPPI Rescheduler v0.4 - (c)2016 Kevin Dorner
Reading configuration files...
Error: could not determine CPU version_num from client_state. Nothing changed.

This is a normal result with Kevvy's 0.51 (and apparently 0.4 as well) in certain cases where there is not swapping of WUs to do, and it is a known outstanding issue. Not a problem, just nothing to do. I would recommend upgrading the Kevvy 0.4 to 0.51 (there's a link a couple pages back), as there were a couple fixes in there you need. I've been working on a replacement for S@h AutoTaskSwap v0.2_beta1.cmd, and am going to be going general release with that shortly. The update does handle non-standard file path installations like yours, without the need to edit the file. I'll shoot you a PM with more details. Later, Jim ...

---

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

Chances are that neither file is a problem and that you are fine and should do nothing! If not, you might try copying client_state_prev.xml, which is another backup, to client_state.xml, if you believe the original got trashed.
First, compare what the web shows you working on to what BoincMgr shows. If they match, there is no problem. If not, let BOINC sort it out. It will.
0.2 copies client_state.xml to client_state_backup.xml before calling GUPPIRescheduler.exe, where client_state_prev.xml is written by the boinc client, presumably as some type of backup also.
I don't imagine there should be a need to reinstall BOINC, based on what you describe. At the worst, you may have trashed a few WUs, but I bet not. One thing I can definitively say is that the Kevvy error message above requires no action on your part. No worries!
Regards, Jim ...

---

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

Before you do that, you might also try copying client_state_prev.xml, which is another backup, to client_state.xml, if you believe the original got trashed. Chances are, though, that neither file is a problem and that you are fine and should do nothing!
Fisrt, compare what the web shows you working on to what BoincMgr shows. If they match, there is no problem. If not, let BOINC sort it out. It will.
0.2 copies client_state.xml to client_state_backup.xml before calling GUPPIRescheduler.exe, where client_state_prev.xml is written by the boinc client, presumably as some type of backup also.
I don't imagine there should be a need to reinstall BOINC, based on what you describe. At the worst, you may have trashed a few WUs, but I bet not. No worries!
Regards, Jim ...

Yoda51 only has one i5-3570K, so it must be host 7219793.

No sign of any trashed tasks there, and the host has reported completed tasks within the last few minutes.

I'd strongly advise not nuking the current BOINC installation until he understands the expected process a little better. And then, it probably won't be needed, anyway.

No sign of any trashed tasks there, and the host has reported completed tasks within the last few minutes.

I'd strongly advise not nuking the current BOINC installation until he understands the expected process a little better. And then, it probably won't be needed, anyway.

Agreed.
0.2 had some serious issues, but the basic backup and invocation of Kevvy's app was solid. Thanks for peeking at the host, I didn't think to ... I am hoping Mr. Kevvy will surface soon and drive a stake through the heart of that particular bug!

---

. . HI,

. . Do not be concerned about that message, when there are no nonVLAR tasks in your CPU cache that is normal and it can occur sometimes when there is only 1 nonVLAR task there. If you wait a while until there are more tasks that need to be moved and then try again it usually works.

Stephen

.

Error messages which frighten people into nuking a perfectly good working installation are something we should avoid, if at all possible.

Even if they're intended to be helpful, informative messages.

Error messages which frighten people into nuking a perfectly good working installation are something we should avoid, if at all possible.

Even if they're intended to be helpful, informative messages.

Agreed.

---

Error messages which frighten people into nuking a perfectly good working installation are something we should avoid, if at all possible.

Even if they're intended to be helpful, informative messages.

Agreed. 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.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

Thank everybody for all your answers: I understood that maybe there is no real trouble or file corruption with autotask batch so I will continue to crunch my workunit and NOT reset boinc project

please note I run GUPPI Rescheduler v0.4 on two other host frequently (host ID: 7570280 and ID: 8021929 with windows7) without using S@h AutoTaskSwap v0.2_beta1.cmd and that i never got: "Error: could not determine CPU version_num from client_state" even if there was not workunit to resheduled: i got only message "NO non GUPPI assigned to CPU, no change made"

"Error: could not determine CPU version_num from client_state. Nothing changed" hapened only on my host ID: 7219793 (using windows 10) and AutoTaskSwap v0.2 and with both version GUPPI Rescheduler v0.4 and v0.51. it hapened more than 10 times one after one, and a few hours later the resheduling was suddenly ok again juste one time. (and always bad since)

maybe it could be related on the content of workunit queue ....

I notice also that on that host (ID: 7219793) all CPU assigned workunit are GUPPY, but on my GPU's i still have a few GUPPY task on queue after several resheduling attemps

---

finaly i notice that my app_info.xml file was 41ko big on the host with probleme and only 11ko big on the 2 other host so i copy one of the smaler file and replace the big 41k file result: resheduling work fine know

lot of line with <name>setiathome_v7 and V8 </name> in the big file
only <name>setiathome_v8</name> in the smal one

---

Error messages which frighten people into nuking a perfectly good working installation are something we should avoid, if at all possible.

Even if they're intended to be helpful, informative messages.

Agreed. If the information message can't be removed entirely, ...

If I could, I would. But I assume that at some point Mr. Kevvy will address this ...

---

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 ?

Hello yoda51,
My frontend script doesn't modify any Boinc files. Only MrK's app does.
Mine only does a backup of client_state.xml in case something goes wrong.

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

If you mean:
1. Stop DLing tasks with the Project Command button: "No new tasks";
2. process all the tasks already DLed and let them Upload and Report back; and then
3. press the Project Command button: "Reset project".
That is a good option and I don't understand why others are concerned.

Au plaisir,
Robert

---

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.

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

Richard might have some better knowledge to share of the internal workings of Boinc since I am just going from what I am observing.

Cheers,
RobG

---

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 he doesn't get the chance before you want to release your QOpt v1.0 front-end, you should probably just include in a text file the known issues/bugs to MrK's v0.51 since this thread is getting way too long for new users to be expected to find such info.

Just my 2cents,
RobG :-)

---