Is the skygrid file in the project directory supposed to remain compressed ...
Yes
Quote:
and when running the application should unpack into the slot directory?
When a task starts crunching, a slot directory is set up which contains everything needed for the processing of the task - both data and programs. Most of these are simply links to the (uncompressed) originals which remain in the E@H project directory. A link is just a file whose contents are the path to where the real file is located on the disk. Each different task has its own slot directory (0, 1, 2, ....).
The skygrid file is different since the original is compressed. BOINC makes an uncompressed copy in the slot directory leaving the original unchanged. At the end of computation when a result is returned and everything is complete, the contents of the slot directory are thrown away and the slot directory may then be reused for a subsequent task.
Bikeman mentions the absence of stderr.txt. By the same token, if that indicates that the program didn't start, why is there a Hough.out clearly showing? I would have thought it would also be missing if the program didn't start.
I guess it is possible for both files to be created in a number of ways, such as by the program as it starts, or as a zero length file by the OS before the program starts (which is later appended to), or perhaps by an internal routine at some point after the program has started when output needs to be made on a particular 'channel'. I'm not a programmer so it's not clear to me why one is there but the other isn't.
You mentioned in your original message that GW tasks were making no progress after many hours which is why your situation looked similar to that of others with the 'no progress' problem. Since your computers are hidden and you haven't given any hostID or taskIDs to look at, it's very hard to say if your problem is the same or not. As Bikeman suggests, and since others have had problems with AV/Security software, your problem may be a little different and may not respond to just the use of anonymous platform (AP) with an app_info.xml file.
Quote:
I tried to simply copy the extracted version of skygrid and it seemed to work until the first checkpoint ...
How do you know this? Was a checkpoint file actually written? Did the restarts commence from a saved checkpoint? You could tell it was starting from a checkpoint if it didn't restart from 0.000% completed but rather some larger value.
Quote:
I tried the XML work around and it didn't really work as expected. Apparently installing it obliterated the two WU's I had for SkySearch.
It is expected that 'in progress' tasks will error out because they have been 'branded' in your state file as being associated with a 'different' set of programs as far as BOINC is concerned. Those tasks weren't making progress so it's probably best that they got returned as an error. Your BOINC client should download new tasks and the interesting thing is if these can be processed with the *_2.exe app under AP.
Quote:
It also seemed not to be able to download the 3.12 versions of the pulsar application.
It's not supposed to. The AP mechanism never downloads any apps. You have to provide them yourself. If you have previously crunched an ABP1 task using 3.12, the app should already be there in your E@H project folder.
Quote:
It made no attempt to retrieve the CUDA versions of the app.
A CUDA app wasn't listed in app_info.xml. That file was constructed for someone who didn't have a CUDA capable GPU. If you want to use the CUDA app you would need to significantly change the app_info.xml file. I don't have an NVIDIA GPU so I don't really know what the names of the various executable files are or what version is current but by looking at the download directory on the website, you can see version 3.13 of the CUDA apps there. So my guess is this following example could be used as an app_info.xml for the case where you wanted to run the CUDA app for ABP1 tasks and the stock *_2.exe app for GW tasks.
This may have been my fault since I had tried the app_info.xml without the Pulsar Search app initially since I was hoping that I could simply override only the settings for the SkySearch. Boinc deleted the local version of the Pulsar Search app when I restarted it.
If you tried a cut down version of app_info.xml, all apps not mentioned will get deleted since BOINC now regards them as being 'surplus to requirements' ;-). When using AP you need to specify all executables and you need to make sure all that are specified do actually exist in the E@H project folder before restarting BOINC. You can get anything that you are missing from the download directory link I gave you above.
Quote:
I saw no attempt to download wu's from the server for skysearch to allow me to determine if the new configuration would allow me to run the skysearch app successfully.
Did you force an update? Is it possible that other projects are being preferred so maybe you just have to wait until BOINC is ready.
Quote:
If I understand correctly it appears all desired apps must be manually specified in the app_info.xml for it to work correctly, it may also be required to somehow download the apps manually (unsure if the issue was a temp server problem or not).
Yes, yes, and no it is not at all a server problem. It's just the way AP works.
Quote:
I removed the app_info.xml temporarily and I only received work for the CUDA version of the pulsar search which Boinc downloaded all required apps as normal.
OK, you should check if the new CUDA apps are exactly as I've listed in the example above. If they are, then fine. If not, you should correct the above example before trying to use it. If you are missing the S5R6 GW apps given in the example, you can download them from the same place. When you have all the matching apps, move the app_info.xml into place and stop and restart BOINC. I think that any CUDA task currently running should continue on the restart but if you want to be safe plan to stop and restart BOINC immediately after the task in progress finishes.
The skygrid file is different since the original is compressed. BOINC makes an uncompressed copy in the slot directory leaving the original unchanged. At the end of computation when a result is returned and everything is complete, the contents of the slot directory are thrown away and the slot directory may then be reused for a subsequent task.
Bikeman mentions the absence of stderr.txt. By the same token, if that indicates that the program didn't start, why is there a Hough.out clearly showing? I would have thought it would also be missing if the program didn't start.
I guess it is possible for both files to be created in a number of ways, such as by the program as it starts, or as a zero length file by the OS before the program starts (which is later appended to), or perhaps by an internal routine at some point after the program has started when output needs to be made on a particular 'channel'. I'm not a programmer so it's not clear to me why one is there but the other isn't.
Placed the modified app_info.xml. Only had to make a small change to the windows graphics file version for the CUDA version in the version section. I'll add back the standard ABP app back if everything goes smoothly initially. I hadn't received any new work for it so the applications hadn't been downloaded again.
So far so good. The existing tasks were restarted as you had mentioned and this time a stderr.txt was generated along with a decompressed copy of the skygrid file (previously, the slot directory just contained a file link to the compressed version in the project folder). After a few minutes I did get a checkpoint file and I appear to be making progress on the S5R6 app now. I did download one new CUDA task for ABP so that part seems to be working, won't know completely until it runs through.
I don't appear to be creating any hanging processess and the app is eating up a healthy 80+ MB of RAM. Currently at 10.1% of progress.
Quote:
You mentioned in your original message that GW tasks were making no progress after many hours which is why your situation looked similar to that of others with the 'no progress' problem. Since your computers are hidden and you haven't given any hostID or taskIDs to look at, it's very hard to say if your problem is the same or not. As Bikeman suggests, and since others have had problems with AV/Security software, your problem may be a little different and may not respond to just the use of anonymous platform (AP) with an app_info.xml file.
Your understanding of the situation was correct. No progress after many hours of processing on a Windows 7, I5-750 machine. I did send Bikeman the info about my AV/Security software.
Original Task Ids:
151099266
151099261
New Tasks (hadn't run these previously)
152018447
152038657
Quote:
Quote:
I tried to simply copy the extracted version of skygrid and it seemed to work until the first checkpoint ...
How do you know this? Was a checkpoint file actually written? Did the restarts commence from a saved checkpoint? You could tell it was starting from a checkpoint if it didn't restart from 0.000% completed but rather some larger value.
Total guess that it was running okay, elapsed time was climbing and it did get past the 3 minute mark which it didn't seem to be doing previously (assumption made on restart messages for the task every 3 minutes of clock time). I didn't pay enough attention to progress and to completion columns to know that it was truly running successfully. I'm guessing a problem occurred at the checkpoint since it restarted the app, from the message log, almost exactly at the 5 minute elapsed time mark and no checkpoint file was created.
Quote:
Quote:
This may have been my fault since I had tried the app_info.xml without the Pulsar Search app initially since I was hoping that I could simply override only the settings for the SkySearch. Boinc deleted the local version of the Pulsar Search app when I restarted it.
If you tried a cut down version of app_info.xml, all apps not mentioned will get deleted since BOINC now regards them as being 'surplus to requirements' ;-). When using AP you need to specify all executables and you need to make sure all that are specified do actually exist in the E@H project folder before restarting BOINC. You can get anything that you are missing from the download directory link I gave you above.
This would explain what I saw, didn't even think of backing up the project directory before trying the app_info.xml file. Will know for next time.
Quote:
Quote:
I saw no attempt to download wu's from the server for skysearch to allow me to determine if the new configuration would allow me to run the skysearch app successfully.
Did you force an update? Is it possible that other projects are being preferred so maybe you just have to wait until BOINC is ready.
I had, but it apparently took a second try before it redownloaded my "lost WUs'. It worked the first time this time. Not sure what was different.
Is there a link to manually download the applications so I can restore the standard ABP application to operational condition? I believe I have what I need for the XML file, but without the application it won't do much.
Is there a link to manually download the applications so I can restore the standard ABP application to operational condition? I believe I have what I need for the XML file, but without the application it won't do much.
Is there a link to manually download the applications so I can restore the standard ABP application to operational condition? I believe I have what I need for the XML file, but without the application it won't do much.
Placed the modified app_info.xml. Only had to make a small change to the windows graphics file version for the CUDA version in the version section.
Thanks for that - I missed one of the 4 3.12 -> 3.13 edits. I've fixed it in the earlier published example app_info.xml file.
Quote:
I'll add back the standard ABP app back if everything goes smoothly initially. I hadn't received any new work for it so the applications hadn't been downloaded again.
I don't know that you can do that. If you look through your tasks list on the website, I think you'll find that all previous ABP1 tasks have been done with the assistance of the GPU. I'm not sure you can do 'CPU only' crunching whilst simultaneously doing GPU crunching. I think your other CPUs get used for GW tasks or for tasks of other projects (if you support other projects).
Quote:
I don't appear to be creating any hanging processess and the app is eating up a healthy 80+ MB of RAM. Currently at 10.1% of progress.
Everything is looking good.
Quote:
Original Task Ids:
151099266
151099261
New Tasks (hadn't run these previously)
152018447
152038657
Thanks for those. It's much easier to imagine what's going on when you can see the tasks list and examine the output of tasks. For instance, I can see that your ABP1 tasks write a checkpoint every 5.5 mins and that all have used the GPU. You don't have any completed GW tasks yet but you have several 'in progress'. They should be writing checkpoints about every minute.
Quote:
Is there a link to manually download the applications so I can restore the standard ABP application to operational condition? I believe I have what I need for the XML file, but without the application it won't do much.
The link I gave in a previous message is the E@H download directory. It's a long list of files and directories. You can ignore the directories - they contain the huge number of data files, etc. Scroll down past those and you will find all the programs that have ever existed. Look for the particular version that you need and download it. A good sanity check is to look at the date. If you think you need to download a program that is dated a couple of years ago then you've obviously got the wrong version. The two CUDA apps are dated 26 Nov 2009 and the two 'CPU only' apps are immediately above those in the list. As I said, I don't know that you need those.
Remember that in normal circumstances, you shouldn't need to download anything. The current 'no progress' problem is being worked around by invoking the AP mechanism - which in turn requires jumping through quite a few hoops. Bernd has said that he will work out a proper fix early in the new year. At that point you should ditch AP and go back to the automatic method.
I'll add back the standard ABP app back if everything goes smoothly initially. I hadn't received any new work for it so the applications hadn't been downloaded again.
I don't know that you can do that. If you look through your tasks list on the website, I think you'll find that all previous ABP1 tasks have been done with the assistance of the GPU. I'm not sure you can do 'CPU only' crunching whilst simultaneously doing GPU crunching. I think your other CPUs get used for GW tasks or for tasks of other projects (if you support other projects).
I seem to remember at least a few CPU ABP's while I was doing CUDA ones. I know SETI will assign both types to my computer maybe I got them confused.
I only found one task with 3.12
151471627
Quote:
Quote:
Is there a link to manually download the applications so I can restore the standard ABP application to operational condition? I believe I have what I need for the XML file, but without the application it won't do much.
The link I gave in a previous message is the E@H download directory. It's a long list of files and directories. You can ignore the directories - they contain the huge number of data files, etc. Scroll down past those and you will find all the programs that have ever existed. Look for the particular version that you need and download it. A good sanity check is to look at the date. If you think you need to download a program that is dated a couple of years ago then you've obviously got the wrong version. The two CUDA apps are dated 26 Nov 2009 and the two 'CPU only' apps are immediately above those in the list. As I said, I don't know that you need those.
Remember that in normal circumstances, you shouldn't need to download anything. The current 'no progress' problem is being worked around by invoking the AP mechanism - which in turn requires jumping through quite a few hoops. Bernd has said that he will work out a proper fix early in the new year. At that point you should ditch AP and go back to the automatic method.
I did have the 3.12 app at one point, so I guess I must have downloaded it for the one task. This is a totally new machine so I've always had this GPU card in it.
Understood, how will the general community know when the fix is in place and that the app_info.xml should be removed to return to normal operation?
Thank you very much for the help, hopefully I'll be able to aid the GW effort now.
I seem to remember at least a few CPU ABP's while I was doing CUDA ones. I know SETI will assign both types to my computer maybe I got them confused.
I only found one task with 3.12
151471627
Yes, that one was crunched on the CPU only. It was done fairly recently and there were a couple of breaks in crunching, the first for about an hour immediately after the first hour of crunching. Maybe that was a switch to a Seti task. The second pause was for just 20 mins quite near the end of crunching. Maybe that was when you switched to AP.
So perhaps you can do both CUDA and non-CUDA simultaneously. If you don't mind risking the odd trashed task, you could try setting up an app_info.xml that covers both s. I imagine you would need to specify all six executables in the section and then have two s, one for 3.12 with two executables and one for 3.13 with four executables and the , , and stuff. Please realise I have no experience and am only guessing.
What you could do is disable network comms and then stop BOINC and make a backup copy of BOINC data folder. Then insert the new app_info.xml and restart BOINC. If it all works, just ditch the backup copy and restore network comms. If it all goes pear shaped, ditch the data directory and restore the backup copy. Once crunching has restarted the old way, just restore network comms. Disabling network comms prevents any errors from being communicated to the server.
Quote:
... how will the general community know when the fix is in place and that the app_info.xml should be removed to return to normal operation?
I'm sure there will be at least a sticky thread and probably front page news as well. Also remember that Oliver has been working on ABP2 and there have been a couple of posts saying that a new version is not far away. It wouldn't surprise me if both things happened at about the same time.
I seem to remember at least a few CPU ABP's while I was doing CUDA ones. I know SETI will assign both types to my computer maybe I got them confused.
I only found one task with 3.12
151471627
Yes, that one was crunched on the CPU only. It was done fairly recently and there were a couple of breaks in crunching, the first for about an hour immediately after the first hour of crunching. Maybe that was a switch to a Seti task. The second pause was for just 20 mins quite near the end of crunching. Maybe that was when you switched to AP.
So perhaps you can do both CUDA and non-CUDA simultaneously. If you don't mind risking the odd trashed task, you could try setting up an app_info.xml that covers both s. I imagine you would need to specify all six executables in the section and then have two s, one for 3.12 with two executables and one for 3.13 with four executables and the , , and stuff. Please realise I have no experience and am only guessing.
What you could do is disable network comms and then stop BOINC and make a backup copy of BOINC data folder. Then insert the new app_info.xml and restart BOINC. If it all works, just ditch the backup copy and restore network comms. If it all goes pear shaped, ditch the data directory and restore the backup copy. Once crunching has restarted the old way, just restore network comms. Disabling network comms prevents any errors from being communicated to the server.
I had considered putting on a block not to request any new work, wait until my current tasks are completed, and update the app_info.xml as you stated. As long as I back up the project folder so I can restore the application exes if needed, I should be okay in this case since there will be no data to corrupt. I'll give you the outcome of it once I know.
Any more effort needed to determine the exact path of the failure or is it pretty well understood now?
Quote:
Quote:
... how will the general community know when the fix is in place and that the app_info.xml should be removed to return to normal operation?
I'm sure there will be at least a sticky thread and probably front page news as well. Also remember that Oliver has been working on ABP2 and there have been a couple of posts saying that a new version is not far away. It wouldn't surprise me if both things happened at about the same time.
RE: Is the skygrid file in
)
Yes
When a task starts crunching, a slot directory is set up which contains everything needed for the processing of the task - both data and programs. Most of these are simply links to the (uncompressed) originals which remain in the E@H project directory. A link is just a file whose contents are the path to where the real file is located on the disk. Each different task has its own slot directory (0, 1, 2, ....).
The skygrid file is different since the original is compressed. BOINC makes an uncompressed copy in the slot directory leaving the original unchanged. At the end of computation when a result is returned and everything is complete, the contents of the slot directory are thrown away and the slot directory may then be reused for a subsequent task.
Bikeman mentions the absence of stderr.txt. By the same token, if that indicates that the program didn't start, why is there a Hough.out clearly showing? I would have thought it would also be missing if the program didn't start.
I guess it is possible for both files to be created in a number of ways, such as by the program as it starts, or as a zero length file by the OS before the program starts (which is later appended to), or perhaps by an internal routine at some point after the program has started when output needs to be made on a particular 'channel'. I'm not a programmer so it's not clear to me why one is there but the other isn't.
You mentioned in your original message that GW tasks were making no progress after many hours which is why your situation looked similar to that of others with the 'no progress' problem. Since your computers are hidden and you haven't given any hostID or taskIDs to look at, it's very hard to say if your problem is the same or not. As Bikeman suggests, and since others have had problems with AV/Security software, your problem may be a little different and may not respond to just the use of anonymous platform (AP) with an app_info.xml file.
How do you know this? Was a checkpoint file actually written? Did the restarts commence from a saved checkpoint? You could tell it was starting from a checkpoint if it didn't restart from 0.000% completed but rather some larger value.
It is expected that 'in progress' tasks will error out because they have been 'branded' in your state file as being associated with a 'different' set of programs as far as BOINC is concerned. Those tasks weren't making progress so it's probably best that they got returned as an error. Your BOINC client should download new tasks and the interesting thing is if these can be processed with the *_2.exe app under AP.
It's not supposed to. The AP mechanism never downloads any apps. You have to provide them yourself. If you have previously crunched an ABP1 task using 3.12, the app should already be there in your E@H project folder.
A CUDA app wasn't listed in app_info.xml. That file was constructed for someone who didn't have a CUDA capable GPU. If you want to use the CUDA app you would need to significantly change the app_info.xml file. I don't have an NVIDIA GPU so I don't really know what the names of the various executable files are or what version is current but by looking at the download directory on the website, you can see version 3.13 of the CUDA apps there. So my guess is this following example could be used as an app_info.xml for the case where you wanted to run the CUDA app for ABP1 tasks and the stock *_2.exe app for GW tasks.
einstein_S5R6
einstein_S5R6_3.01_windows_intelx86_2.exe
einstein_S5R6_3.01_graphics_windows_intelx86.exe
einsteinbinary_ABP1
einsteinbinary_ABP1_3.13_graphics_windows_intelx86__ABP1cuda23.exe
einsteinbinary_ABP1_3.13_windows_intelx86__ABP1cuda23.exe
cudart.dll
cufft.dll
einstein_S5R6
301
6.3.0
einstein_S5R6_3.01_windows_intelx86_2.exe
einstein_S5R6_3.01_graphics_windows_intelx86.exe
graphics_app
einsteinbinary_ABP1
313
cuda
1.0
1.0
CUDA
1
6.7.0
einsteinbinary_ABP1_3.13_windows_intelx86__ABP1cuda23.exe
einsteinbinary_ABP1_3.13_graphics_windows_intelx86__ABP1cuda23.exe
graphics_app
cudart.dll
cufft.dll
If you tried a cut down version of app_info.xml, all apps not mentioned will get deleted since BOINC now regards them as being 'surplus to requirements' ;-). When using AP you need to specify all executables and you need to make sure all that are specified do actually exist in the E@H project folder before restarting BOINC. You can get anything that you are missing from the download directory link I gave you above.
Did you force an update? Is it possible that other projects are being preferred so maybe you just have to wait until BOINC is ready.
Yes, yes, and no it is not at all a server problem. It's just the way AP works.
OK, you should check if the new CUDA apps are exactly as I've listed in the example above. If they are, then fine. If not, you should correct the above example before trying to use it. If you are missing the S5R6 GW apps given in the example, you can download them from the same place. When you have all the matching apps, move the app_info.xml into place and stop and restart BOINC. I think that any CUDA task currently running should continue on the restart but if you want to be safe plan to stop and restart BOINC immediately after the task in progress finishes.
EDIT: Fixed typo (3.12 -> 3.13) in app_info.xml
Cheers,
Gary.
RE: The skygrid file is
)
Placed the modified app_info.xml. Only had to make a small change to the windows graphics file version for the CUDA version in the version section. I'll add back the standard ABP app back if everything goes smoothly initially. I hadn't received any new work for it so the applications hadn't been downloaded again.
So far so good. The existing tasks were restarted as you had mentioned and this time a stderr.txt was generated along with a decompressed copy of the skygrid file (previously, the slot directory just contained a file link to the compressed version in the project folder). After a few minutes I did get a checkpoint file and I appear to be making progress on the S5R6 app now. I did download one new CUDA task for ABP so that part seems to be working, won't know completely until it runs through.
I don't appear to be creating any hanging processess and the app is eating up a healthy 80+ MB of RAM. Currently at 10.1% of progress.
Your understanding of the situation was correct. No progress after many hours of processing on a Windows 7, I5-750 machine. I did send Bikeman the info about my AV/Security software.
Original Task Ids:
151099266
151099261
New Tasks (hadn't run these previously)
152018447
152038657
Total guess that it was running okay, elapsed time was climbing and it did get past the 3 minute mark which it didn't seem to be doing previously (assumption made on restart messages for the task every 3 minutes of clock time). I didn't pay enough attention to progress and to completion columns to know that it was truly running successfully. I'm guessing a problem occurred at the checkpoint since it restarted the app, from the message log, almost exactly at the 5 minute elapsed time mark and no checkpoint file was created.
This would explain what I saw, didn't even think of backing up the project directory before trying the app_info.xml file. Will know for next time.
I had, but it apparently took a second try before it redownloaded my "lost WUs'. It worked the first time this time. Not sure what was different.
Is there a link to manually download the applications so I can restore the standard ABP application to operational condition? I believe I have what I need for the XML file, but without the application it won't do much.
RE: Is there a link to
)
Hi!
Point your webbrowser to http://einstein.astro.gla.ac.uk/download/ and select the appropriate windows exes.
CU
Bikeman
RE: RE: Is there a link
)
Thanks, I'll make the configuration changes ones the current WU's work there way through.
Still seems to be working, 2 are a bit over 30% complete and another just shy of 20%. Appears the xml was a good workaround for my machine.
Thanks to both of you.
RE: Placed the modified
)
Thanks for that - I missed one of the 4 3.12 -> 3.13 edits. I've fixed it in the earlier published example app_info.xml file.
I don't know that you can do that. If you look through your tasks list on the website, I think you'll find that all previous ABP1 tasks have been done with the assistance of the GPU. I'm not sure you can do 'CPU only' crunching whilst simultaneously doing GPU crunching. I think your other CPUs get used for GW tasks or for tasks of other projects (if you support other projects).
Everything is looking good.
Thanks for those. It's much easier to imagine what's going on when you can see the tasks list and examine the output of tasks. For instance, I can see that your ABP1 tasks write a checkpoint every 5.5 mins and that all have used the GPU. You don't have any completed GW tasks yet but you have several 'in progress'. They should be writing checkpoints about every minute.
The link I gave in a previous message is the E@H download directory. It's a long list of files and directories. You can ignore the directories - they contain the huge number of data files, etc. Scroll down past those and you will find all the programs that have ever existed. Look for the particular version that you need and download it. A good sanity check is to look at the date. If you think you need to download a program that is dated a couple of years ago then you've obviously got the wrong version. The two CUDA apps are dated 26 Nov 2009 and the two 'CPU only' apps are immediately above those in the list. As I said, I don't know that you need those.
Remember that in normal circumstances, you shouldn't need to download anything. The current 'no progress' problem is being worked around by invoking the AP mechanism - which in turn requires jumping through quite a few hoops. Bernd has said that he will work out a proper fix early in the new year. At that point you should ditch AP and go back to the automatic method.
Cheers,
Gary.
RE: RE: I'll add back the
)
I seem to remember at least a few CPU ABP's while I was doing CUDA ones. I know SETI will assign both types to my computer maybe I got them confused.
I only found one task with 3.12
151471627
I did have the 3.12 app at one point, so I guess I must have downloaded it for the one task. This is a totally new machine so I've always had this GPU card in it.
Understood, how will the general community know when the fix is in place and that the app_info.xml should be removed to return to normal operation?
Thank you very much for the help, hopefully I'll be able to aid the GW effort now.
RE: I seem to remember at
)
Yes, that one was crunched on the CPU only. It was done fairly recently and there were a couple of breaks in crunching, the first for about an hour immediately after the first hour of crunching. Maybe that was a switch to a Seti task. The second pause was for just 20 mins quite near the end of crunching. Maybe that was when you switched to AP.
So perhaps you can do both CUDA and non-CUDA simultaneously. If you don't mind risking the odd trashed task, you could try setting up an app_info.xml that covers both s. I imagine you would need to specify all six executables in the section and then have two s, one for 3.12 with two executables and one for 3.13 with four executables and the , , and stuff. Please realise I have no experience and am only guessing.
What you could do is disable network comms and then stop BOINC and make a backup copy of BOINC data folder. Then insert the new app_info.xml and restart BOINC. If it all works, just ditch the backup copy and restore network comms. If it all goes pear shaped, ditch the data directory and restore the backup copy. Once crunching has restarted the old way, just restore network comms. Disabling network comms prevents any errors from being communicated to the server.
I'm sure there will be at least a sticky thread and probably front page news as well. Also remember that Oliver has been working on ABP2 and there have been a couple of posts saying that a new version is not far away. It wouldn't surprise me if both things happened at about the same time.
Cheers,
Gary.
RE: RE: I seem to
)
I had considered putting on a block not to request any new work, wait until my current tasks are completed, and update the app_info.xml as you stated. As long as I back up the project folder so I can restore the application exes if needed, I should be okay in this case since there will be no data to corrupt. I'll give you the outcome of it once I know.
Any more effort needed to determine the exact path of the failure or is it pretty well understood now?
Sounds great, Thanks.