For Beta Testers - How to Interpret the app_info.xml file
20 Oct 2007 5:48:16 UTC
Topic 193246
(moderation:
It's really useful for the Devs if participants in the project are prepared to undergo the potential pain and suffering of running the beta test apps. Bernd has said on quite a few occasions that he has found beta tests to be very useful and I would also like to thank those who have made the effort to participate.
EDIT: 23 October 07
When a boinc client requests work from a project server, information about the "platform" (the combination of hardware and OS) on which the client is running is sent to the server. This allows the server to make sure that the correct science app is installed on the client machine. The platform must be one that the server understands or you cannot get work.
The purpose of the app_info.xml file is to set up the "Anonymous Platform Mechanism", ie the server doesn't need to identify your platform and doesn't attempt to send you any science app at all. You are telling the server that you are providing suitable app(s) and can accept certain versions of work as defined in the app_info.xml file. If the server has that work available it will simply send it to you as needed.
The key to participating successfully is in making sure you understand how the app_info.xml file (distributed in each beta test package) controls what is happening on your computer during a beta test. I have quite a number of machines running beta apps so I have found it necessary to understand the mechanism so that I know what is supposed to happen and can make adjustments (if needed) to suit my particular requirements. The following commentary is intended to encourage potential beta testers to join the program and learn to interpret the app_info mechanism for themselves.
Firstly, let us examine the file distributed with the Windows 4.13 beta test app and dissect it piece by piece. The excerpts from the file are in red text. The interpretation of the code is in black and follows immediately AFTER the code snippet.
einstein_S5R3
The above declares that what follows is purely for the S5R3 run which has the official name as stated.
einstein_S5R3_4.13_windows_intelx86.exe
einstein_S5R3_4.13_windows_intelx86.pdb
This says that there are two particular files that you need to provide and install for the S5R3 run and that their full names are as declared here. The first one is an executable and the second is a support file. You will need to provide both of these or you will get complaints!!
einstein_S5R3
407
einstein_S5R3_4.13_windows_intelx86.exe
einstein_S5R3_4.13_windows_intelx86.pdb
The above says that for the case of the S5R3 run, if you have in your cache, results that are "branded" with 4.07 as the appropriate version for crunching, then it is quite safe and appropriate that these results be crunched with these main program and support files as listed (ie 4.13 version).
einstein_S5R3
411
einstein_S5R3_4.13_windows_intelx86.exe
einstein_S5R3_4.13_windows_intelx86.pdb
The above says that for the case of the S5R3 run, if you have in your cache, results that are "branded" with 4.11 as the appropriate version for crunching, then it is quite safe and appropriate that these results be crunched with these main program and support files as listed (ie 4.13 version).
einstein_S5R3
413
einstein_S5R3_4.13_windows_intelx86.exe
einstein_S5R3_4.13_windows_intelx86.pdb
The above says that for the case of the S5R3 run, if you have in your cache, results that are "branded" with 4.13 as the appropriate version for crunching, then it is quite safe and appropriate that these results be crunched with these main program and support files as listed (ie 4.13 version).
This is the last section of the current app_info.xml file and 4.13 is the highest declared version number. This means that any new work added to your cache while this file is current will be automatically "branded" with the 4.13 version. This "branding" is in the client_state.xml file and doesn't get changed when you change beta apps. This is why your pre-existing cache of work gets reported as having been crunched by the old "brand" version even although the crunching would have been done by the new beta app once installed.
So now that you know how to interpret the app_info.xml file, you can see that the current one is declaring that it is quite safe to crunch any 4.07 or 4.11 work in your cache with the new beta app. That being the case, with 4.07 being the current production app, you can immediately join the beta test system or upgrade from an older beta by doing the following:-
-
* Download and unpack the three files from the current beta package
* Completely stop boinc and confirm stopped
* Copy the three new files into your einstein project folder, allowing any previous app_info.xml to be overwritten
* Restart boinc and continue on from where the previous app left off.
In my case I have extra requirements so I add to the app_info.xml file before I install it. I'll present a fully documented example but first a bit of background.
We are still actually in the transition from S5R2 to S5R3 and probably still will be for a few more weeks yet as resends continue to be sent out. If you are participating in the current beta tests, the app_info.xml file (as distributed) only allows you to participate in S5R3 work. This ensures that you cannot get any of those resends even if you already have the appropriate large data files in your system. In other words some other non beta test participant will probably be sent all those large data files, possibly for just a single resend result. I have a large number of computers participating in the beta test and all of mine can get resends of S5R2 work at any time. Even now, quite a few of them do. Mostly it's for large data files that are already on the system but occasionally I've noticed a download of new large data files just for one or a few resends.
To participate in these resends, here is the code I use which is in addition to the standard code distributed in the beta package. I put this extra code right at the start immediately after the opening tag.
einstein_S5R2
einstein_S5R2_4.33_windows_intelx86.exe
einstein_S5R2_4.33_windows_intelx86.pdb
einstein_S5R2
433
einstein_S5R2_4.33_windows_intelx86.exe
einstein_S5R2_4.33_windows_intelx86.pdb
This code declares that this computer is capable of participating in any remaining S5R2 work using the 4.33 versions of the executable and .pdb files as listed. If I remember correctly there was a higher number "official" version but 4.33 was a bit faster so I chose to use it for the cleanup of resends :).
If you want an example of how this is working, take a look at this results list for a host that is still cleaning up resends of S5R2 work at the moment. It's a dual core PIII 1Gig machine with 10 tasks in the cache. The oldest 6 are S5R2 results and the final 2 of those will finish in just under 2 days time, ie on 22 October. The newest 4 tasks are S5R3 and branded 4.13. They will be done with the current beta app unless Bernd brings out another one before they get started :).
EDIT: 23 October 07
As mentioned above, the final two S5R2 results did finish on October 22. The machine now has only S5R3 work in its cache but it could still receive more S5R2 if it became available (ie through an outstanding result from some other cruncher exceeding the deadline without being returned).
So this is the advantage for me of modifying the current app_info.xml file. I can support the beta test and also help clean up resends at the same time.
Please realise that I'm NOT advocating that people rush out and start modifying the app_info.xml file without fully understanding exactly what they are doing. If there is the slightest doubt, please DO NOT make any modifications. I'm advocating that people joining the beta test program really can benefit from understanding the mechanism. S5R2 resends will die out soon enough so what I've done has a fairly limited "shelf life" now. The beauty is that I don't have to pay any attention to it as S5R3 will get done when there is no more S5R2.
Cheers,
Gary.
For Beta Testers - How to Interpret the app_info.xml file
)
I have just picked up a S5R2 Wu and using a app_info about what you explanied but I´m using 4.40 since the I don´t have the pdb for 4.33 is their a way to get this so I can finish the WU unit with 4.33 that started with 4.40, and can one finish with 4.33 a WU started with 4.40.
RE:
)
The precise question of what listing two files really does/means is a point I'm a bit foggy on.
My impression is that the science ap gets told where to get the executable from by this mechanisms, but not anything else. In other words, I don't thing ap_info redefines references to other files, which are instead found by the executable on its own. So listing the .pdb may just be a textual comment, or may enlist the aid of some support code to check that it is present. Anyone know?
The thing I know is that I've seen ap_info.xml files listing as many as three files in simultaneous use with ones listing only the executable, both working when all was well.
Thanks for all this *very
)
Thanks for all this *very good* information! It is very valuable to me, as the app_info.xml file continues to frustrate me when I need to make modifications. Your breakdown really helps!
However
Why doesn't this project just use an opt-in option in the project settings like many other modern BOINC projects? That way there is no need for all this file manipulation any more.
Reno, NV
Team: SETI.USA
RE: I have just picked up a
)
That's fine. Any late version of the S5R2 app can be used to finish off any resends you happen to get. I just happened to have both 4.33 files and from my own observations and comments on these boards, I knew that 4.33 would be a bit faster. However you should use whatever version you have available.
No, not officially, although someone who has it could send it to you if you really are desperate :).
Yes, of course. You would just need to modify the app_info.xml file to say that version 440 can be crunched by einstein_S5R2_4.33_windows_intelx86.exe. This would succeed because the checkpoint saved by 4.40 before you shut it down is compatible with and can be read by other versions such as 4.33. This isn't always the case so you have to pay attention to Bernd's announcements and be aware when there might be changes that wont allow this to succeed.
Cheers,
Gary.
RE: RE: I have just
)
Thanks for the answer. I´ll keep crunching with 4.40 then so nothing happen.
RE: My impression is that
)
My understanding is that this mechanism says that the boinc client should not consult the server to be told about the official app for this project. Rather, the client is to accept that the named science app is the correct one to use and that this app (and any required supporting files) will already be available in the usual place - the einstein project folder in this case. Only the executable really needs to be specified and be present for things to work. However, since this is a beta test, it is important that the symbol information (in the .pdb file) be also available so that a useful stack dump can be created if the app errors out at some point. By specifying the .pdb file in the app_info.xml file you actually ensure that a complaint gets raised if the .pdb is missing.
I'm not sure I understand what you are referring to here. Can you elaborate or perhaps give an example, thanks?
Cheers,
Gary.
RE: Thanks for all this
)
You're welcome! I'm pleased that you found it useful
I'm sorry but I can't answer this as I'm not really familiar with what other projects do or what an "opt-in option" actually is. Can you explain it a bit?
Cheers,
Gary.
RE: By specifying the .pdb
)
That is the answer to my question. Thanks.
As a test, I just now stopped BOINC, removed the .pdb file from the Einstein directory, and restarted.
It did indeed raise an error, but not on initially reading ap_info, but instead on starting up processing of an actual result. Each result--it ripped through my entire Einstein queue erroring out all Einstein results in a very few seconds. (all by the time I looked).
Don't try this at home.
Oddly enough, when I put the .pdb file back and restarted BOINC, I _did_ get a startup error:
[error]Deleting file xxxx.pdb while in use
Then it went into a sulk--communication with project postponed for 24 hours.
Not the most graceful set of behaviors I ever saw, but, indeed, "a complaint gets raised if the .pdb is missing" when one specifies it in the ap_info file.
My confirming experiment was one of the more destructive I've run hereabouts, but at least I do understand the mechanism's behavior a bit better.
RE: RE: RE: I have just
)
Couldn´t keep cool, found a link to the pdb in a earlier thread. Started up crunching with 4.33 where 4.40 left off, no error meassges. Hopefully I haven´t wastied anything but that a long wait since it´s a 660+ Cr WU.
RE: I'm sorry but I can't
)
Sure. Many projects, Malaria Control for example, have a setting the user can turn on/off in the project settings portion of their account. If checked, the project server will send beta applications and/or WUs to the user's machines. Here is a snapshot:
http://homepage.mac.com/zombie67/mc.png
Reno, NV
Team: SETI.USA