From the app_info.xml in einstein_S5R4_6.02_i686-pc-linux-gnu.tar.gz:
6.3.0
I suppose it won't make any difference?
I'm not sure where you would have got the gzipped tarfile that you quoted and I'm equally puzzled as to why what is now the stock app would contain an app_info.xml file since it's not needed to just run stock S5R4. I didn't see any tarfiles in the download directory I linked to but perhaps you have found a tarfile where the new app may have been tested internally by project staff and therefore needed to be run under the AP mechanism? How did you get that file?
In any case, I just used the api_version as specified in the last S5R3 test apps that were released a couple of months ago. I don't think it has any significant effect on what I'm trying to do, ie be dual capable under BOINC 5.10.45. If I was trying to run "bleeding edge" BOINC I would probably be a bit more concerned :-). I'm sure if anyone knows more about the significance of that particular variable, they will tell us about it. My testing didn't reveal any problems with the 6.1.0 value.
Thank you. I'm running BOINC 5.10.45, so I'll set api_version to 6.1.0, and restart BOINC when the S5R3 task queue drops below one day.
After doing some research on the downloaded 6.02 files, I found that the execute permission was missing. After adding it and downloading a new S5R4 WU, the S5R4 WU seems to be crunching OK.
Something like this (missing execute permission under Linux) was reported some time ago but my brain is a bit useless these days and I don't recall the details. Somebody more on the ball than me will probably chime in with a link to the previous info.
I downloaded all the files for S5R4 from the EAH download directory (as linked) using firefox and "save link as ..." to place them on a Windows share that all my Linux hosts and Windows hosts could access. My Linux hosts see it as a samba share. Any given Linux host just copies what it needs from the samba share and the files do have the execute bit set. I've just checked and they have rwxr--r-- permissions, the owner being gary:gary as intended.
I'm sorry that you had that trouble.
When dealing with Linux (Ubuntu) I am very much a noob. I tried getting Einstein to run sometime last year and had the same problems, although I WAS successful in running S@H. It was probably the same issue as well, but I didn't know it at the time.
Anyway, up and running on that system now. Quota is currently 2 WU/cpu, but they take long enough I'll return some and bump that before I run dry. One more Linux system to go, but I know what to watch for now.
My Windows systems came over without a problem (still have 1 left to do...knock on wood).
I have tested this file on a couple of machines and it works for me. I take no responsibility for what happens to you as a result of using this file. If you don't have a clue what this is all about then you really shouldn't be using it until you do a bit of research on what has been written already about this.
To use this file you need to cut and paste what appears below into a text file which you will call app_info.xml. You will place this file together with all the Windows executables I listed in my previous message, into your Einstein project directory, overwriting any previous app_info.xml that might be there. You will then stop and restart BOINC.
A word to those who have never tried an app_info.xml file here.
If you add this file, BOINC does exactly what it reads and throws anything
else away - if you've spent 5 hrs on some work and app_info.xml doesnt explicitly
mention the program you crunched it on, that work is deleted immediately.
Best if you (a) wait till you've uploaded your work. and (b) make a copy of all your data before restarting BOINC!
Thanks very much for your feedback. I'm sorry I couldn't reply earlier but I've had sudden and unexpected work commitments that have severely limited my ability to respond in a timely manner.
When taken out of context, my disclaimer probably does seem a bit harsh :-). I felt I needed something with a bit of "shock value" to make people really aware that things could easily go wrong.
I was really trying to indicate that this is quite a complex situation and I don't have time to cover (or even the skill to foresee) every single potential "gotcha" that can come along. What I should have been more clear about is that the information I'm posting in this thread is specifically for experienced people already familiar with the workings of the AP mechanism because they've been using it previously to run beta test and power user apps and are therefore competent both to get into the AP mechanism in the first place and also to bail out when they might change their minds.
I should have done the extra leg-work and pointed people to further reading such as this message in this thread where archae86 had correctly identified the simplest and most reliable technique for reverting from the AP mechanism where the user has to supply specific apps to the more normal stock situation where the appropriate default apps are auto-sent as required.
I should have also told people that there were very important messages elsewhere in the thread I've just linked to which should be deemed "required reading".
Now having got my apology out of the way, let me thank you for trying to warn people about the dangers of using AP, but let me also add some extra stuff that will hopefully clarify the information you have provided :-).
Quote:
A word to those who have never tried an app_info.xml file here.
These people were not the intended audience. My intention was to assist people already experienced with the AP mechanism and therefore already using app_info.xml. I simply wanted to assist those people to make their hosts "dual app" capable by providing them with a modified version of their existing app_info.xml files.
Quote:
... if you've spent 5 hrs on some work and app_info.xml doesnt explicitly
mention the program you crunched it on, that work is deleted immediately.
I know I'm nitpicking but I think it's important. The app_info.xml file doesn't need to name the program that did the 5 hrs of crunching. The app_info file needs to name the new program you will be using when you restart and it needs to give permission for that new program to be used for the partly crunched task. It does this by having a series of clauses that give explicit permission for tasks "branded" with a particular version number to be crunched with the new app of choice. If the required clause doesn't exist, then the partly crunched task will be thrown away together with any other unstarted tasks that are also "branded" with the now unsupported version number.
I was very careful to state my assumptions up front by saying that the app_info file would assume that the tasks likely to be in a user's cache should be branded with either 4.36 or 4.46 (for a Windows host). What I didn't tediously point out was the possibility that some people might have joined early on (eg. version 4.15) and then simply not kept up-to-date with the later and greater test app versions as they were announced. I assumed that people would understand that if they had been using a now unsupported version app, they couldn't expect that what I was providing would actually work for them without further modification.
The fix for this is to add extra clauses to the app_info file, one for each extra old version number that needed to be supported. This was left as an exercise for the reader. If you needed to support version 4.15, you could simply duplicate the version 4.36 clause and change the "436" into "415".
Quote:
Best if you (a) wait till you've uploaded your work. and (b) make a copy of all your data before restarting BOINC!
If you are going to give people option (b) you should also clearly tell them that they should be disconnected from the internet at the time they restart. If things go pear shaped and the client reports the mayhem to the server, it's then too late for a backup to be of much use.
Please don't take any of the above as any form of criticism of your feedback. I do appreciate your message and I thought it would be a good opportunity to further explain things for the benefit of all others who might be following this. Hopefully experienced people will make their hosts "dual capable" so that the scheduler can send the inevitable resends to willing hosts rather than just simply co-opting the first poor sucker who comes along looking for work :-).
EDIT:
Sorry, I hadn't read rbpeake's message and your follow-up reply where you have added the extra bit about being offline. The AP mechanism is very much like quicksand - easy to drop into but hard to get back out if you try to do so in a hurry :-).
I would strongly advise against grabbing stuff from there as a lot of it seems to be "work in progress" that is being internally tested and therefore liable to cause havoc if a "not ready for release" version gets out into the wild. Just look at some of the comments against some of the packages and you will get the impression that the sensible thing to do is back right out of there :-).
I may be wrong but it appears to me that "ready for use" versions get put into the download directory and are therefore much more likely to be safe to use.
I may be wrong but it appears to me that "ready for use" versions get put into the download directory and are therefore much more likely to be safe to use.
That's a good point Gary and you are absolutely right. Binaries from the CVS repository (the first link) should only be tested stand alone (the very curious can test this with the reference workunit provided by Bernd, for example), but not for crunching in the project.
I would strongly advise against grabbing stuff from there as a lot of it seems to be "work in progress" that is being internally tested and therefore liable to cause havoc if a "not ready for release" version gets out into the wild. Just look at some of the comments against some of the packages and you will get the impression that the sensible thing to do is back right out of there :-).
I may be wrong but it appears to me that "ready for use" versions get put into the download directory and are therefore much more likely to be safe to use.
I wanted to confirm that you are correct. There are executable versions which go into the CVS archive but which then fail our internal testing and hence are never released. This will not happen (or is much less likely!) if you take executables from the Einstein@Home download server download/ directory.
Another approach, as the S5R4 stock client can make use of SSE, will be to let the S4R3 cache run down completely then D/L the stock client.
I suppose another way would be to detach from the project and reattach, when all the results from completed S5R3s are sent?
The way I did it was to just set Einstein to no new work on the projects tab in BOINCmgr. Once it had finished and reported the wu's (took a couple of days) I deleted app_info.xml from the einstein.phys.uwm.edu folder.
That way it will download what it needs. It also deletes the old (in my case power-user) apps. I have since had a few S5R3b as well as getting a heap of S5R4a wu's to process.
The way I did it was to just set Einstein to no new work on the projects tab in BOINCmgr. Once it had finished and reported the wu's (took a couple of days) I deleted app_info.xml from the einstein.phys.uwm.edu folder.
That is the correct procedure for backing out of the AP mechanism completely.
Quote:
That way it will download what it needs. It also deletes the old (in my case power-user) apps. I have since had a few S5R3b as well as getting a heap of S5R4a wu's to process.
Yes you are back to stock apps only. I'm starting to notice now, more resend (S5R3) tasks than there were a couple of days ago. You may be getting more as well. In your case, if you are, you will have downloaded the S5R3 stock app to crunch them with and you will have lost the advantage of the optimised app you were originally using that has now been deleted.
With the majority of people now converted to S5R4, the resend tasks are becoming more available for those of us who are advertising to the scheduler, our ability to handle them. The scheduler seems to hold the resends for a period while it waits for a suitable host to come along. This is going pretty much like the R2/R3 transition that occurred 10+ months ago.
I've noticed recently, some new info on the server status page which allows us to know approximately how many old tasks there are still to come back. Currently it's a minimum of around 65K. It will be more than that since some quorums may have both tasks still outstanding and, in the future, even more tasks will be sent out since a fraction of what is currently out there will timeout and have to be issued yet again. It's also very interesting to see there are still 2 S5R2 resends yet to come in :-).
For anyone interested, I've added an edit to the message about the Windows app_info.xml file that was posted back at the start of this thread. The purpose of the edit is to make the Windows app_info file able to handle tasks that had originally been downloaded with the stock version 4.26 Windows app. Anyone currently running the "dual capable" AP mechanism successfully, will not need this. It's only of interest if you have 4.26 "branded" tasks in your cache and were thinking of trying out the AP mechanism to become "dual capable" for optimised apps.
I'm looking at flushing queue of S5R3s and understand that I surely will never get any S5R3s even though I use dual capability app_info.xml
Is there anybody who did get some work from S5R3 with dual app_info?
I mean who crunches S5R4 and then suddenly get S5R3 work a little.
RE: RE: RE:
)
I got it from the binaries/apps directory. The executables are the same as those in the download directory.
Thank you. I'm running BOINC 5.10.45, so I'll set api_version to 6.1.0, and restart BOINC when the S5R3 task queue drops below one day.
RE: RE: After doing some
)
When dealing with Linux (Ubuntu) I am very much a noob. I tried getting Einstein to run sometime last year and had the same problems, although I WAS successful in running S@H. It was probably the same issue as well, but I didn't know it at the time.
Anyway, up and running on that system now. Quota is currently 2 WU/cpu, but they take long enough I'll return some and bump that before I run dry. One more Linux system to go, but I know what to watch for now.
My Windows systems came over without a problem (still have 1 left to do...knock on wood).
Seti Classic Final Total: 11446 WU.
RE: RE: I have tested
)
Thanks very much for your feedback. I'm sorry I couldn't reply earlier but I've had sudden and unexpected work commitments that have severely limited my ability to respond in a timely manner.
When taken out of context, my disclaimer probably does seem a bit harsh :-). I felt I needed something with a bit of "shock value" to make people really aware that things could easily go wrong.
I was really trying to indicate that this is quite a complex situation and I don't have time to cover (or even the skill to foresee) every single potential "gotcha" that can come along. What I should have been more clear about is that the information I'm posting in this thread is specifically for experienced people already familiar with the workings of the AP mechanism because they've been using it previously to run beta test and power user apps and are therefore competent both to get into the AP mechanism in the first place and also to bail out when they might change their minds.
I should have done the extra leg-work and pointed people to further reading such as this message in this thread where archae86 had correctly identified the simplest and most reliable technique for reverting from the AP mechanism where the user has to supply specific apps to the more normal stock situation where the appropriate default apps are auto-sent as required.
I should have also told people that there were very important messages elsewhere in the thread I've just linked to which should be deemed "required reading".
Now having got my apology out of the way, let me thank you for trying to warn people about the dangers of using AP, but let me also add some extra stuff that will hopefully clarify the information you have provided :-).
These people were not the intended audience. My intention was to assist people already experienced with the AP mechanism and therefore already using app_info.xml. I simply wanted to assist those people to make their hosts "dual app" capable by providing them with a modified version of their existing app_info.xml files.
I know I'm nitpicking but I think it's important. The app_info.xml file doesn't need to name the program that did the 5 hrs of crunching. The app_info file needs to name the new program you will be using when you restart and it needs to give permission for that new program to be used for the partly crunched task. It does this by having a series of clauses that give explicit permission for tasks "branded" with a particular version number to be crunched with the new app of choice. If the required clause doesn't exist, then the partly crunched task will be thrown away together with any other unstarted tasks that are also "branded" with the now unsupported version number.
I was very careful to state my assumptions up front by saying that the app_info file would assume that the tasks likely to be in a user's cache should be branded with either 4.36 or 4.46 (for a Windows host). What I didn't tediously point out was the possibility that some people might have joined early on (eg. version 4.15) and then simply not kept up-to-date with the later and greater test app versions as they were announced. I assumed that people would understand that if they had been using a now unsupported version app, they couldn't expect that what I was providing would actually work for them without further modification.
The fix for this is to add extra clauses to the app_info file, one for each extra old version number that needed to be supported. This was left as an exercise for the reader. If you needed to support version 4.15, you could simply duplicate the version 4.36 clause and change the "436" into "415".
If you are going to give people option (b) you should also clearly tell them that they should be disconnected from the internet at the time they restart. If things go pear shaped and the client reports the mayhem to the server, it's then too late for a backup to be of much use.
Please don't take any of the above as any form of criticism of your feedback. I do appreciate your message and I thought it would be a good opportunity to further explain things for the benefit of all others who might be following this. Hopefully experienced people will make their hosts "dual capable" so that the scheduler can send the inevitable resends to willing hosts rather than just simply co-opting the first poor sucker who comes along looking for work :-).
EDIT:
Sorry, I hadn't read rbpeake's message and your follow-up reply where you have added the extra bit about being offline. The AP mechanism is very much like quicksand - easy to drop into but hard to get back out if you try to do so in a hurry :-).
Cheers,
Gary.
RE: I got it from the
)
Ahhh..... OK.
I would strongly advise against grabbing stuff from there as a lot of it seems to be "work in progress" that is being internally tested and therefore liable to cause havoc if a "not ready for release" version gets out into the wild. Just look at some of the comments against some of the packages and you will get the impression that the sensible thing to do is back right out of there :-).
I may be wrong but it appears to me that "ready for use" versions get put into the download directory and are therefore much more likely to be safe to use.
Cheers,
Gary.
RE: I may be wrong but it
)
That's a good point Gary and you are absolutely right. Binaries from the CVS repository (the first link) should only be tested stand alone (the very curious can test this with the reference workunit provided by Bernd, for example), but not for crunching in the project.
CU
Bikeman
RE: RE: I got it from the
)
I wanted to confirm that you are correct. There are executable versions which go into the CVS archive but which then fail our internal testing and hence are never released. This will not happen (or is much less likely!) if you take executables from the Einstein@Home download server download/ directory.
Cheers,
Bruce
Director, Einstein@Home
RE: Another approach, as
)
The way I did it was to just set Einstein to no new work on the projects tab in BOINCmgr. Once it had finished and reported the wu's (took a couple of days) I deleted app_info.xml from the einstein.phys.uwm.edu folder.
That way it will download what it needs. It also deletes the old (in my case power-user) apps. I have since had a few S5R3b as well as getting a heap of S5R4a wu's to process.
BOINC blog
RE: The way I did it was to
)
That is the correct procedure for backing out of the AP mechanism completely.
Yes you are back to stock apps only. I'm starting to notice now, more resend (S5R3) tasks than there were a couple of days ago. You may be getting more as well. In your case, if you are, you will have downloaded the S5R3 stock app to crunch them with and you will have lost the advantage of the optimised app you were originally using that has now been deleted.
With the majority of people now converted to S5R4, the resend tasks are becoming more available for those of us who are advertising to the scheduler, our ability to handle them. The scheduler seems to hold the resends for a period while it waits for a suitable host to come along. This is going pretty much like the R2/R3 transition that occurred 10+ months ago.
I've noticed recently, some new info on the server status page which allows us to know approximately how many old tasks there are still to come back. Currently it's a minimum of around 65K. It will be more than that since some quorums may have both tasks still outstanding and, in the future, even more tasks will be sent out since a fraction of what is currently out there will timeout and have to be issued yet again. It's also very interesting to see there are still 2 S5R2 resends yet to come in :-).
Cheers,
Gary.
For anyone interested, I've
)
For anyone interested, I've added an edit to the message about the Windows app_info.xml file that was posted back at the start of this thread. The purpose of the edit is to make the Windows app_info file able to handle tasks that had originally been downloaded with the stock version 4.26 Windows app. Anyone currently running the "dual capable" AP mechanism successfully, will not need this. It's only of interest if you have 4.26 "branded" tasks in your cache and were thinking of trying out the AP mechanism to become "dual capable" for optimised apps.
Cheers,
Gary.
I'm looking at flushing queue
)
I'm looking at flushing queue of S5R3s and understand that I surely will never get any S5R3s even though I use dual capability app_info.xml
Is there anybody who did get some work from S5R3 with dual app_info?
I mean who crunches S5R4 and then suddenly get S5R3 work a little.