Believe me - I've been monitoring to see if the devs have got it right! This was v6.10.25:
Are any of the versions with the deby bug fixed stable enough to upgrade to? I'm running 6.10.11 on my CUDA pc. A a non-cuda system with a newer install has 6.10.18.
Believe me - I've been monitoring to see if the devs have got it right! This was v6.10.25:
Are any of the versions with the deby bug fixed stable enough to upgrade to? I'm running 6.10.11 on my CUDA pc. A a non-cuda system with a newer install has 6.10.18.
They've been steadily improving (under constant nagging from alpha testers), but unfortunately I took them back a few steps with a bug report yesterday.
For Windows use (my platform), I'd say that any of v6.10.19, .20 or .21 gives the widest range of available projects. AQUA, which is pioneering multi-threaded apps, is the hardest to get right.
Well, but why are you using an app_info.xml in the first place?
That is a fair question, with more than one answer. Dan has mentioned the transition handling issue as it regards already downloaded work, especially in the presence of multiple projects with a high mismatch in effort allocation.
A matter which motivates me, but perhaps few others, is the fact that I run a COMODO firewall with settings which mean that the system asks me to give a ruling the first time any new executable is invoked. In the case of BOINC aps, if I am not there to give permission, after a little while it errors out in a way that trashes the result, then flies right along burning off the inventory of work in a few minutes. By the time I notice, typically there is no work, and work fetch is disabled until the next day for reason of having burned up the 1 result/core/day quota as reduced for the errors.
Using ap_info is one way to avoid this happening, especially when I leave a host unattended for days. It does, however, haver other disadvantages.
What I was hoping to be able to do was to have my app info assign new s5r6 WU's to the s5r6 default executable while not causing those assigned to the old s5r5 exe to crash.
I would not bother for S5R5 anymore, it's basically over. I don't think there are still WUs around for S5R5, but if there are, they can easily be collected by ATLAS or whoever.
What I was hoping to be able to do was to have my app info assign new s5r6 WU's to the s5r6 default executable while not causing those assigned to the old s5r5 exe to crash.
I would not bother for S5R5 anymore, it's basically over. I don't think there are still WUs around for S5R5, but if there are, they can easily be collected by ATLAS or whoever.
CU
H-B
You misunderstand. Lingering stuff in my app info (from when s5r6 was still using the old r5 app???) is sending all my s5r6 wu's to the s5r5 executable. I'm wondering if the problem is that the person who wrote the app info consuming code never considered that critical version data would be stored somewhere other than in the version field and that as a result the version_num value of a newer application might be lower than that of an older one.
Shorn of the ABP2 entries (assumed to be irrelevant) my current appinfo file is the following:
Upps.... I don't think this is healthy, currently there is no 3.05 S5R6 app for Windows (the app version didn't change so it's x.01 on all platforms), but there could be in the future, so you don't want to have a 305 S5R6 version in your app_info.xml.
And given the fact that the ABP2 app will probably undergo some change (optimizations) in the near future, everyone's better off without app_info.xml to get the latest ABP2 apps as soon as they are rolled out.
What about suspending the other projects while the Einstein@Home cache is drained with "no noew work"?
As plan B, you could also disable network-traffic, stop BOINC, backup the whole BOINC installation, edit the client_state.xml file to change all false 305 version "brandings", remove the 305 stuff from app_info.xml and restart BOINC. See if it does the trick, if not, restore from backup ...
Upps.... I don't think this is healthy, currently there is no 3.05 S5R6 app for Windows (the app version didn't change so it's x.01 on all platforms), but there could be in the future, so you don't want to have a 305 S5R6 version in your app_info.xml.
Actually, he doesn't have a S5R6_3.05 app in his app_info.xml. He has a S5R5_3.05 app.
Effectively his app_info.xml says he is doing the S5R6 run but that if he has tasks branded as 301, he will use the app S5R6_3.01 (which is correct) but if he has tasks branded as 305, he will use the app S5R5_3.05. Of course, because 305 is the higher version, all R6 tasks are being crunched with the S5R5_3.05 app.
This is actually working. I've checked his host and his tasks are indeed being crunched with the former S5R5_3.05 app and they are validating. So it must be that there were no changes in the app between S5R5 and S5R6. Of course this is pure luck and a highly undesirable state of affairs.
You could attempt surgery on client_state.xml and app_info.xml to get out of this but I believe the best course of action would be not to attempt that, mainly because the editing task would be quite onerous and the chance of mistakes, quite high. Instead, if it were my host, I'd set NNT and abort all unstarted tasks. I'd wait for the currently crunching tasks to finish and be reported. I'd delete app_info.xml and then I'd stop and restart BOINC. If you didn't want to waste quite so many tasks (seeing as they are validating) you could set NNT and run the cache down for a while before doing the abort thing.
If Dan were to take copies of the currently legitimate GW (S5R6_3.01) and ABP2 apps that are in his project folder, he could check they were still there just before restarting BOINC. If they were not, he could replace them and BOINC will find them and actually skip the downloading of all the apps once again. If he's not concerned about bandwidth, he could ignore this tip and let BOINC download afresh after a project reset.
Everything is being crunched by the s5r5 3.05 application.
I'm not a total control of app_info guy, but the symptom you describe is actually what this version asks for. The primary key is the app_name, and you this section routes S5R6 straight to an S5R5 executable.
Edit: I see that Gary made a more useful version of this comment while I was away typing.
I am currently NNT, but I normally keep a 4 day cache to ride out any network outages and on my i7 that's ~ 100 tasks remaining. Were I to attempt an abortfest now I'd end up starving my client when E@H decided to stop sending me WU's because of my problems.
You could attempt surgery on client_state.xml and app_info.xml to get out of this but I believe the best course of action would be not to attempt that, mainly because the editing task would be quite onerous and the chance of mistakes, quite high. Instead, if it were my host, I'd set NNT and abort all unstarted tasks. I'd wait for the currently crunching tasks to finish and be reported. I'd delete app_info.xml and then I'd stop and restart BOINC. If you didn't want to waste quite so many tasks (seeing as they are validating) you could set NNT and run the cache down for a while before doing the abort thing.
12 minutes and 3 restores from backup to have the existing work units running on the current executable via app info.
First restore PEBKAC diagnosis of the problem
Second restore PEBKAC diagnosis of the problem
Third restore realized the binaries I'd copied over earlier had been cleaned up, also copied app_version data from second machine.
When I nuke the app_info.xml file itself all my WU's are still imploding and I'm not sure what needs thumped to fix that.
RE: Believe me - I've been
)
Are any of the versions with the deby bug fixed stable enough to upgrade to? I'm running 6.10.11 on my CUDA pc. A a non-cuda system with a newer install has 6.10.18.
RE: RE: Believe me - I've
)
They've been steadily improving (under constant nagging from alpha testers), but unfortunately I took them back a few steps with a bug report yesterday.
For Windows use (my platform), I'd say that any of v6.10.19, .20 or .21 gives the widest range of available projects. AQUA, which is pioneering multi-threaded apps, is the hardest to get right.
RE: Well, but why are you
)
That is a fair question, with more than one answer. Dan has mentioned the transition handling issue as it regards already downloaded work, especially in the presence of multiple projects with a high mismatch in effort allocation.
A matter which motivates me, but perhaps few others, is the fact that I run a COMODO firewall with settings which mean that the system asks me to give a ruling the first time any new executable is invoked. In the case of BOINC aps, if I am not there to give permission, after a little while it errors out in a way that trashes the result, then flies right along burning off the inventory of work in a few minutes. By the time I notice, typically there is no work, and work fetch is disabled until the next day for reason of having burned up the 1 result/core/day quota as reduced for the errors.
Using ap_info is one way to avoid this happening, especially when I leave a host unattended for days. It does, however, haver other disadvantages.
Dan, RE: What I was
)
Dan,
I would not bother for S5R5 anymore, it's basically over. I don't think there are still WUs around for S5R5, but if there are, they can easily be collected by ATLAS or whoever.
CU
H-B
RE: Dan, RE: What I was
)
You misunderstand. Lingering stuff in my app info (from when s5r6 was still using the old r5 app???) is sending all my s5r6 wu's to the s5r5 executable. I'm wondering if the problem is that the person who wrote the app info consuming code never considered that critical version data would be stored somewhere other than in the version field and that as a result the version_num value of a newer application might be lower than that of an older one.
Shorn of the ABP2 entries (assumed to be irrelevant) my current appinfo file is the following:
[pre]
einstein_S5R6
einstein_S5R6_3.01_windows_intelx86__S5R6sse2.exe
einstein_S5R6_3.01_graphics_windows_intelx86.exe
einstein_S5R5_3.05_windows_intelx86.exe
einstein_S5R5_3.05_windows_intelx86_0.exe
einstein_S5R5_3.05_windows_intelx86_1.exe
einstein_S5R5_3.05_windows_intelx86_2.exe
einstein_S5R5_3.05_graphics_windows_intelx86.exe
einstein_S5R6
301
6.7.0
einstein_S5R6_3.01_windows_intelx86__S5R6sse2.exe
einstein_S5R6_3.01_graphics_windows_intelx86.exe
graphics_app
einstein_S5R6
305
6.3.0
einstein_S5R5_3.05_windows_intelx86.exe
einstein_S5R5_3.05_windows_intelx86_0.exe
einstein_S5R5_3.05_windows_intelx86_1.exe
einstein_S5R5_3.05_windows_intelx86_2.exe
einstein_S5R5_3.05_graphics_windows_intelx86.exe
graphics_app
[/pre]
Everything is being crunched by the s5r5 3.05 application.
Upps.... I don't think this
)
Upps.... I don't think this is healthy, currently there is no 3.05 S5R6 app for Windows (the app version didn't change so it's x.01 on all platforms), but there could be in the future, so you don't want to have a 305 S5R6 version in your app_info.xml.
And given the fact that the ABP2 app will probably undergo some change (optimizations) in the near future, everyone's better off without app_info.xml to get the latest ABP2 apps as soon as they are rolled out.
What about suspending the other projects while the Einstein@Home cache is drained with "no noew work"?
As plan B, you could also disable network-traffic, stop BOINC, backup the whole BOINC installation, edit the client_state.xml file to change all false 305 version "brandings", remove the 305 stuff from app_info.xml and restart BOINC. See if it does the trick, if not, restore from backup ...
CU
H-B
RE: Upps.... I don't think
)
Actually, he doesn't have a S5R6_3.05 app in his app_info.xml. He has a S5R5_3.05 app.
Effectively his app_info.xml says he is doing the S5R6 run but that if he has tasks branded as 301, he will use the app S5R6_3.01 (which is correct) but if he has tasks branded as 305, he will use the app S5R5_3.05. Of course, because 305 is the higher version, all R6 tasks are being crunched with the S5R5_3.05 app.
This is actually working. I've checked his host and his tasks are indeed being crunched with the former S5R5_3.05 app and they are validating. So it must be that there were no changes in the app between S5R5 and S5R6. Of course this is pure luck and a highly undesirable state of affairs.
You could attempt surgery on client_state.xml and app_info.xml to get out of this but I believe the best course of action would be not to attempt that, mainly because the editing task would be quite onerous and the chance of mistakes, quite high. Instead, if it were my host, I'd set NNT and abort all unstarted tasks. I'd wait for the currently crunching tasks to finish and be reported. I'd delete app_info.xml and then I'd stop and restart BOINC. If you didn't want to waste quite so many tasks (seeing as they are validating) you could set NNT and run the cache down for a while before doing the abort thing.
If Dan were to take copies of the currently legitimate GW (S5R6_3.01) and ABP2 apps that are in his project folder, he could check they were still there just before restarting BOINC. If they were not, he could replace them and BOINC will find them and actually skip the downloading of all the apps once again. If he's not concerned about bandwidth, he could ignore this tip and let BOINC download afresh after a project reset.
Cheers,
Gary.
RE: much
)
I'm not a total control of app_info guy, but the symptom you describe is actually what this version asks for. The primary key is the app_name, and you this section routes S5R6 straight to an S5R5 executable.
Edit: I see that Gary made a more useful version of this comment while I was away typing.
I am currently NNT, but I
)
I am currently NNT, but I normally keep a 4 day cache to ride out any network outages and on my i7 that's ~ 100 tasks remaining. Were I to attempt an abortfest now I'd end up starving my client when E@H decided to stop sending me WU's because of my problems.
RE: You could attempt
)
12 minutes and 3 restores from backup to have the existing work units running on the current executable via app info.
First restore PEBKAC diagnosis of the problem
Second restore PEBKAC diagnosis of the problem
Third restore realized the binaries I'd copied over earlier had been cleaned up, also copied app_version data from second machine.
When I nuke the app_info.xml file itself all my WU's are still imploding and I'm not sure what needs thumped to fix that.