Message boards :
Number crunching :
GUPPI Rescheduler for Linux and Windows - Move GUPPI work to CPU and non-GUPPI to GPU
Message board moderation
Previous · 1 . . . 13 · 14 · 15 · 16 · 17 · 18 · 19 . . . 37 · Next
Author | Message |
---|---|
Stephen "Heretic" Send message Joined: 20 Sep 12 Posts: 5557 Credit: 192,787,363 RAC: 628 |
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 . |
Stubbles Send message Joined: 29 Nov 99 Posts: 358 Credit: 5,909,255 RAC: 0 |
HELLO to all readers of this thread! The last rescheduler 0.51 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 |
Jimbocous Send message Joined: 1 Apr 13 Posts: 1856 Credit: 268,616,081 RAC: 1,349 |
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. GUPPIRescheduler 0.51 is from Mr. Kevvy, btw. Do appreciate the kudos, though :) |
Keith Myers Send message Joined: 29 Apr 01 Posts: 13164 Credit: 1,160,866,277 RAC: 1,873 |
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) |
[AF>HFR]yoda51 Send message Joined: 16 May 99 Posts: 13 Credit: 218,099,206 RAC: 90 |
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... |
Jimbocous Send message Joined: 1 Apr 13 Posts: 1856 Credit: 268,616,081 RAC: 1,349 |
... I get folowing error: 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 ... |
Jimbocous Send message Joined: 1 Apr 13 Posts: 1856 Credit: 268,616,081 RAC: 1,349 |
i think i will restart seti project/resintall boinc after crunshing all workunit in place.... 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 ... |
Richard Haselgrove Send message Joined: 4 Jul 99 Posts: 14678 Credit: 200,643,578 RAC: 874 |
i think i will restart seti project/resintall boinc after crunshing all workunit in place.... 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. |
Jimbocous Send message Joined: 1 Apr 13 Posts: 1856 Credit: 268,616,081 RAC: 1,349 |
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! |
Stephen "Heretic" Send message Joined: 20 Sep 12 Posts: 5557 Credit: 192,787,363 RAC: 628 |
. . 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 . |
Richard Haselgrove Send message Joined: 4 Jul 99 Posts: 14678 Credit: 200,643,578 RAC: 874 |
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. |
Jimbocous Send message Joined: 1 Apr 13 Posts: 1856 Credit: 268,616,081 RAC: 1,349 |
Error messages which frighten people into nuking a perfectly good working installation are something we should avoid, if at all possible. Agreed. |
Keith Myers Send message Joined: 29 Apr 01 Posts: 13164 Credit: 1,160,866,277 RAC: 1,873 |
Error messages which frighten people into nuking a perfectly good working installation are something we should avoid, if at all possible. 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) |
[AF>HFR]yoda51 Send message Joined: 16 May 99 Posts: 13 Credit: 218,099,206 RAC: 90 |
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 |
[AF>HFR]yoda51 Send message Joined: 16 May 99 Posts: 13 Credit: 218,099,206 RAC: 90 |
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 |
Jimbocous Send message Joined: 1 Apr 13 Posts: 1856 Credit: 268,616,081 RAC: 1,349 |
Error messages which frighten people into nuking a perfectly good working installation are something we should avoid, if at all possible. If I could, I would. But I assume that at some point Mr. Kevvy will address this ... |
Stubbles Send message Joined: 29 Nov 99 Posts: 358 Credit: 5,909,255 RAC: 0 |
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)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 |
Stubbles Send message Joined: 29 Nov 99 Posts: 358 Credit: 5,909,255 RAC: 0 |
If not, you might try copying client_state_prev.xml, which is another backup, to client_state.xml. 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 |
Jeff Buck Send message Joined: 11 Feb 00 Posts: 1441 Credit: 148,764,870 RAC: 0 |
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. |
Stubbles Send message Joined: 29 Nov 99 Posts: 358 Credit: 5,909,255 RAC: 0 |
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 :-) |
©2024 University of California
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.