The only reason I stopped the boinctray.exe process is because I thought it might be restarting the Boinc Client sometimes before it had finished saving the changes.

The only programs I know which restart Boinc Client (boinc.exe) are:
- BOINC Manager (boincmgr.exe) - after 30 seconds of "disappearance" of Boinc Client the BOINC Manager restarts it (maybe only if Boinc Client was started initially by BOINC Manager)
- BoincTasks (if set to do so by "Start BOINC client, when BoincTasks starts")

---

 


- ALF - "Find out what you don't do well ..... then don't do it!" :)
 

Thanks for your feedback BilBg!

WRT your 1st point, I wanted to keep my initial release as simple as possible in order for others with limited batch file knowledge to be able to fairly easily understand the logic and steps, so that's why I documented some "assumptions" in the ReadMe file.

I contributed the registry query code which BilBg quoted, for use in the bench test suite: it's also used in the Lunatics installer. Although it took some head-scratching to write it, it's been used for many years now, on multiple versions of both BOINC and Windows. I think you could safely borrow it, with less danger that it will cause problems than your assumption that everyone has accepted Berkeley's default folder locations.

[More people will probably use the default program location, but a high proportion of your target audience will have relocated the DATADIR, either to reduce wear and tear on an SSD system disk, or simply to avoid data loss when periodically nuking their Windows installation. I don't know why, but that's what they do.]

Is there a central place in GIThub where SETIzens can post their code for others to centrally modify?

Shared SETI-specific code is generally kept in the SVN repository described at Porting and optimizing SETI@home. Write access is strictly limited to recognised volunteer developers (see the AUTHORS list in the application documentation): while you are reaching that level of accreditation within the community, the existing developers may be willing to commit code to the repository for you.

The only reason I stopped the boinctray.exe process is because I thought it might be restarting the Boinc Client sometimes before it had finished saving the changes.

The only programs I know which restart Boinc Client (boinc.exe) are:
- BOINC Manager (boincmgr.exe) - after 30 seconds of "disappearance" of Boinc Client the BOINC Manager restarts it (maybe only if Boinc Client was started initially by BOINC Manager)
- BoincTasks (if set to do so by "Start BOINC client, when BoincTasks starts")

The Lunatics Installer also attempts to re-start the client if it stopped it to make changes to app_info.xml. If the client was stopped manually prior to running the installer, it will need to be restarted manually, too. The Installer doesn't need to close the Manager (or BoincTasks, if that's what the user prefers): that's an implicit assumption that modern crunch-worthy computers can move a few megabytes around their filing system in much less than 30 seconds.

Thanks BilBG & Richard.

As I mentioned:

I am looking for others to take over future changes to that script.

and considering it might become popular prior to SETI WoW 2016 event, I think it would be good to adapt it sooner than later as you both suggested.
So if any dev wants to include it to SNV feel free to do so.
...and I'll remain available for testing.

As for Mr Kevvy's script, I'll let him answer about any pref he might have.

Thanks again for the critical feedback in a positive form,
Rob ;-)

[More people will probably use the default program location, but a high proportion of your target audience will have relocated the DATADIR, either to reduce wear and tear on an SSD system disk, or simply to avoid data loss when periodically nuking their Windows installation. I don't know why, but that's what they do.]

Even for those using the default DATADIR location, it's different on an XP system than on later Windows systems, so a hard-coded "C:\ProgramData\BOINC" isn't going to work for those users. Registry lookup is really the only way to go.

What a nice tool :)
Unfortunately, it doesn't seem to work with me...

Salut Laurent,
Any luck in getting it to work?
Au plaisir,
Robert

Is there anyway to request GUPPI only for GPU at this time?
I prefer those to MB. Lower temp on GPU and higher rack/time.

Hey Dean,
None that I know of.
The only option in your webPrefs in your account settings is to not get MB or AP tasks (not subsets).

The only suggestion that might indirectly attain your goal is to send Guppis from the CPU to GPU.
I have a .cmd file that I created prior to Mr Kevvy releasing his script.
It is automated except for the task reassignment which uses Sublime Text 3's "Find & Replace All" to walk the user to do the 4 keystokes that I hadn't automated yet.
If you'd like it, I could make it public "as-is".

Let me know.
Cheers,
Rob :-)

PS: I was going to use PowerShell to automate the CPU-GPU task swap for Cuda50 app only but since Mr. Kevvy released his script before I started to learn powerShell, I didn't bother since his script looks for other parameters that are not only found in client_state.xml

It seems to me your C++ code assumes too much.

E.g. this assumes a new line and exactly 4 spaces before </other_result>:

currentposition = sched_request.find("</app_version>\n    </other_result>");

(There should be a way to just skip any white-space (spaces, tabs, \n \r))

This expects "three-character version_num" (which will probably change for SETI@home v10)
version_numCPU = client_state.substr(nextposition, 3); // Extract the three-character version_num


If you decide some time to make another version of GUPPIRescheduler you may find some XML open source C++ libraries which should ease the parsing and changing of client_state.xml

I found this list:
http://en.cppreference.com/w/cpp/links/libs

... which lists:
http://www.xmlsoft.org/
http://pugixml.org/
http://www.grinninglizard.com/tinyxml/
http://xerces.apache.org/xerces-c/

---

 


- ALF - "Find out what you don't do well ..... then don't do it!" :)
 

If you decide some time to make another version of GUPPIRescheduler you may find some XML open source C++ libraries which should ease the parsing and changing of client_state.xml

And some basic XML-parsing ability provided with BOINC/SETI code itself.
We use it to parse SETI data files (WUs) that are XML-ones too.

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

I've been trying to work out where the code for *writing* those pseudo-XML files might hide in the client sources, but I haven't found it yet..

My suspicion is that they are written with a very simplistic character-based routine, so rigid assumptions like 'four spaces per indent' are likely to work for the forseeable future.

But there are wrinkles like -

client_state.xml is written (under Windows) with CRLF line endings, so - in practice - it can be edited with Windows utilities like Notepad.

sched_request and sched_reply are intended for server use only, so are written with *nix CR-only line endings.

Apple versions may differ in either or both cases...

printf FTW!

printf FTW!

I got as far as

        for (i=0; i<app_versions.size(); i++) {
            if (app_versions[i]->project == p) {
                app_versions[i]->write(f);
            }
        }

in cs_statefile.cpp, where write(f) appears to output an entire structure in XML format, presumably converting structure element names into xml tags, and selecting data format (boolean, numeric, string) according to type declaration.

But searching the source tree for a declaration of write() threw up too many hits...

printf FTW!

I got as far as

        for (i=0; i<app_versions.size(); i++) {
            if (app_versions[i]->project == p) {
                app_versions[i]->write(f);
            }
        }

in cs_statefile.cpp, where write(f) appears to output an entire structure in XML format, presumably converting structure element names into xml tags, and selecting data format (boolean, numeric, string) according to type declaration.

But searching the source tree for a declaration of write() threw up too many hits...

If wanting to grasp the full intent of C++ (which I imagine you might be), then any Berkeley code could be considered 'pretty rough'. In this case just assume write() is writing what you think it should, and if it isn't complain to the author (which in many ways is simpler than analysing deeper)

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

If wanting to grasp the full intent of C++ (which I imagine you might be), then any Berkeley code could be considered 'pretty rough'. In this case just assume write() is writing what you think it should, and if it isn't complain to the author (which in many ways is simpler than analysing deeper)

Read back down the thread to BilBg's message 1805311. The object of the exercise was to determine how rigidly the formatting "a new line and exactly 4 spaces" was imposed on the output file, so we could collectively advise Mr. Kevvy whether the switch to a full open-source XML parser was really necessary for reliable reading. Perhaps the three-digit version number is a more important case in point.

If wanting to grasp the full intent of C++ (which I imagine you might be), then any Berkeley code could be considered 'pretty rough'. In this case just assume write() is writing what you think it should, and if it isn't complain to the author (which in many ways is simpler than analysing deeper)

Read back down the thread to BilBg's message 1805311. The object of the exercise was to determine how rigidly the formatting "a new line and exactly 4 spaces" was imposed on the output file, so we could collectively advise Mr. Kevvy whether the switch to a full open-source XML parser was really necessary for reliable reading. Perhaps the three-digit version number is a more important case in point.

That certainly narrows the scope. Yes I would agree with BillBg that the whitespace issue (and probably others) would likely be fragile, even though the precise string formats may not have deviated on any platform since early clients.

For that issue switching to a 'proper' XML library shouldn't be necessary though. In client + server, The match_tag() based parsing, that is a mash of C and C++, *should be* working to ignore leading + trailing whitespace for a given tag content. [though certainly worth verifying/rejecting, likewise between tags should be ignored fine]

Determining the rigidity/fragility of numerical tags is more complex, because there is no XML schema I'm aware of, so how the individual tag contents are parsed/written can (AFAIK) only be determined by code walking on a case by case basis.

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

... can (AFAIK) only be determined by code walking on a case by case basis.

Which is why I was looking for that write() function...

On a general note: I would expect machine-written XML to be consistent from instance to instance (successive copies of client_state.xml on the same machine shouldn't vary in format, even if there are some systemic differences between platforms).

Where we would really need a proper generic parser would be to cope with the vagaries of human-edited XML.

... can (AFAIK) only be determined by code walking on a case by case basis.

Which is why I was looking for that write() function...

On a general note: I would expect machine-written XML to be consistent from instance to instance (successive copies of client_state.xml on the same machine shouldn't vary in format, even if there are some systemic differences between platforms).

Where we would really need a proper generic parser would be to cope with the vagaries of human-edited XML.

Yeah. More formally for clarification of where the shortcuts are, translation from human readable format into variables/structures in memory constitutes Lexer component for tokenising (see https://en.wikipedia.org/wiki/Lexical_analysis, and a parser component, ( https://en.wikipedia.org/wiki/Parsing), often combined.

This is true for 'proper' XML as well, where usually there is a schema document that describes the lexicon and syntax rules

With Generic C implementation, the traditional approach would be to use lexer and parser generators, that spit out blocks of C code to function standalone or as part of a library or program.

In the case of a more modern C++ style approach, the tokens (in our case 'xml like' tags) the knowledge/information within the objects themselves (encapsulation, information hiding and polymorphism)

Each approach has benefits and disadvantages. The C case being fragile to erroneous input, and the object/C++ case being more robust and flexible, while more resource costly.

Boinc's lexicon and parsing syntactic rules for these files are combined in hard code (which is fine, making a single pass, no external files), but inherits the fragility of the C case, and the bloat of the object based case.

Down the road, since there are probably few to no platforms without C++ capability, I'd be in full favour of an effort to formalise Boinc's custom breed of xml.

Not so much for the sakes of 'correctness', but current future application development is pointing squarely toward the use of 'Domain specific languages' to drive automation like this:

Human readable tasks--->
Low Level Virtual Machine (LLVM Compiler + frontend + backends) +
DSL application(s) --- Generated optimised code.

Sounds fanciful at first, and when you witness thigns working like that it's impressive, however we do those steps via manual (error prone) operations now, at developer, project and user levels. The Android mobile SDK, Cuda, OpenCL and Clang compilers already moved down this road. We're just mostly stuck with fragile custom development until the costs/resources of switching become manageable.

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

@Mr. Kevvy: Has your GUPPIrescheduler ever been tried with stock?

Just some quick feedback. App working well. First time I ran it on my 3 crunchers, it moved about 60-70 workunits to and fro on each machine. I just ran it again on each machine when I shut them down for peak power usage interval and it moved about 15 workunits. Seems to move a 1:1 swap of VLAR-non- guppi workunits. Already noticed a nice bump in RAC on each machine. Now just need to create a batch file for the app to make it easier to run instead of using the command prompt interface. Good job Mr. Kevvy!

Hey Keith,
That's great!
I'd appreciate it if you could try out my front-end script (*.cmd) to automate Mr. Kevvy's script (.exe). The link is the last one in Mr Kevvy's original post at the top...and here it is again: front-end .CMD batch file for Windows
Cheers,
Rob :-)

. . HI,

. . With drop box it helps if you make your uploaded files public access, otherwise I cannot get it.

@Mr. Kevvy: Has your GUPPIrescheduler ever been tried with stock?

Yes, and for most people it should work with it.

---