Windows S5R3 App 4.07 available for Beta Test
26 Sep 2007 9:55:59 UTC
Topic 13597
(moderation:
A new Windows App is available from our Beta Test Page.
This App addresses two problems that are mentioned in the "Client Errors of S5R2 Apps" thread in the "Problems and Bug Reports" Forum.
It features a new checkpointing mechanism and code that has been implemented from scratch without the legacies from older Apps and their requirements. It is much more simple and thus, I hope, more reliable. However the checkpoint files are incompatible with the previous ones, thus there can't be a "smooth transition" from the current official App to this Beta.
This App also features a somewhat dynamic decision whether to run graphics or not. It will start up without the graphics libraries GDI32.DLL, OPENGL32.DLL and GLU32.DLL, will try to load them on its own and in case of a failure it will run without graphics instead of crashing with a client error.
As a side effect you can now tell the App to run without graphics at all (for testing or performance reasons) by putting a file EAH_NO_GRAPHICS into the BOINC directory.
Both features haven't been tested much internally, so we rely on you testers even more than before.
Note that with the app_info.xml included here you will only procees and get S5R3 "work". The scheduler, however, doesn't ask for the Apps first, so as long as there are still many S5R2 workunits in the pool you might get some "No work from project - remove app_info.xml to get more E@H Work" messages if the scheduler happens to pick some of these for you. Unfortunately the S5R3 Apps aren't able to process S5R2 work (technically they can, but the results will be found invalid when compared to those of S5R2 Apps).
BM
BM
Windows S5R3 App 4.07 available for Beta Test
)
That's good news, I guess.
Are you sure that this is a difference in the Apps? I think that the setup of S5R3 should in general stretch the startup time compared to S5R2. I'm not aware of any change that should make this differ between S5R3 Apps 4.01 and 4.07.
It isn't designed for doing so, and I doubt that it will make any difference in that situation from the previous version. Would be nice to know, though.
BM
BM
I see that it probably makes
)
I see that it probably makes more sense to run this Beta if you already got S5R3 work.
BM
BM
RE: RE: As a side effect
)
I usually navigate to the BOINC folder (usually in Program Files) with the Windows Explorer, right-click in the folder, chose "New..." -> "Text Document" and rename it to EAH_NO_GRAPHICS (you must have set to view the file extensions of known filetypes to make this work).
The App should look for the file whenever it is started. You can stop the Boinc Client (Exit the Boinc Manager) and restart it to restart the App and see the effect.
BM
BM
RE: Am I correct that this
)
You're wrong. It shouldn't have any extension at all.
BM
BM
RE: What I think happened
)
That's a very accurate description of the situation.
The setup of S5R3 (splitting up the sky to get smaller workunits) apparently has some effect on the runtime of our App that we haven't been anticipating, and we are still digging for the reason of the large variation in runtime for the same number of templates (which is expressed in the pre-assigned credits). Binding the credit to the number of templates was a natural choice for the "Fstat Search" we used up to S5RI, and we found it worked for the "Hierarchical Search" of S5R2, too, but apparently it doesn't work very well for this program with the setup of S5R3.
A credit / hour comparison of the BOINC projects based on the hosts that are attached to multiple projects can normally be found here, though currently the database seems to be down. This is what we're looking at from time to time to see if we're not too far off with the credits on average.
BM
BM
RE: It's not good behaviour
)
No it's not. But that box comes from the Operating system, not from the App. How much RAM do you have in that machine?
BM
BM
RE: I do wish they'd do
)
Honestly I don't know what to do more about that.
The 4.15 App now forced to sync its checkpoints to disk, there shouldn't be a delay anymore even there.
On a correct filesystem I don't know which files a 'system restore' should touch that affect the work of BOINC (anyone any clue?).
Your last error is quite interesting. Accoding to stderr_out the App has finished the work correctly and isn't called again; i.e. everything looks fine from the App side. Yet still the task is reported as a Client error. This rather looks like a problem with the core client than with the App, e.g. if the client_state.xml was affected by the system restore, but not the data in the slots directories.
If SETI on the same machine and Client isn't affected, I'd rather consider this pure accident, maybe made more likely by project-specific differences (task runtimes, deadlines etc.).
If anyone got a clue what happens or what to improve in the App, I'd be glad to hear.
BM
BM