If computers have same name. Sign into your e@h account. Click view at Computers on this account. Click show all computers. Then click on Merge computers by name. Should work.
I have 2 "compters" listed at E@H. Their CPUs are identified as ARM and ARMv7 Processor rev 5 (v7l). Interesting listing since both are for the same Raspberry Pi2 B, but with different SD cards.
My original card failed, and I replaced it - had to do a reinstall and used a newer Raspi OS.
Is there any way to rename one of these so they can be merged? My interest is in recovering the 4 tasks that were in progress on the failed SD. Perhaps they can be re-acquired, but I see no option to allow me to request that.
... Interesting listing since both are for the same Raspberry Pi2 B, but with different SD cards.
The differences are probably due to the change from BOINC 7.0.27 --> 7.4.23. The newer BOINC probably detects the hardware more correctly.
Quote:
Is there any way to rename one of these so they can be merged?
For merging to work, you probably just need to wait for all tasks to disappear from the online database for the defunct host ID.
Quote:
My interest is in recovering the 4 tasks that were in progress on the failed SD. Perhaps they can be re-acquired, but I see no option to allow me to request that.
There isn't an option to do that but you can make it happen if you ask the scheduler nicely :-). You have to recreate the old host ID and the scheduler will respond to it and send the 'in progress' tasks as 'lost tasks'. Obviously you need to do this before the deadline - which starts 1st Dec.
I've done this many times before and it has always worked since Einstein has the option to 'resend lost tasks'. You just need to reinstate the old host ID and then contact the scheduler. Here are some detailed instructions. My BOINC tree starts at /home/gary/boinc/ - you just need to adjust paths for your situation.
* Stop BOINC and save a complete copy of your entire BOINC tree. Just copy recursively whilst preserving file attributes (cp -rp ... ) to a new name such as boinc.save. If your stuff is in multiple places, you may need to copy more than once. When you have finished with the old host ID you will be restoring this copy so be careful to save it fully and correctly.
* With the duplicate copy saved, you will now convert your current installation into one that is set up for your old host ID so that you can access the outstanding tasks there. NB: Don't touch anything in boinc.save. All edits are confined to the current tree and not the saved copy. To do this you need to find and edit (with a plain text editor) your state file client_state.xml. Essentially you will be deleting the bulk of the file between two particular editing points (inclusive).
* The first editing point is the line that immediately follows the closing tag. You are keeping the blocks for , , and and deleting what comes next. In my case that's an tag.
* The second editing point is about 10 lines from the end of the file. You will see a tag followed by stuff. The line immediately before this should be the closing tag for and this is the second edit point. You need to make all info about tasks, results, workunits, etc disappear so the scheduler will take pity on you and send all the correct info back to you. So just delete all lines between the two editing points inclusive, making sure you don't have any blank lines or disturbed formatting as a result of the deletions.
* In the stuff that is left, you need to make three further edits. The 1st edit is the value for . On your new ID it is currently '1' but it could have changed by the time you start to follow these instructions. On your old ID it is '24' and that shouldn't change. You need to increment it by one to '25' and insert this value for .
* The second edit is to change the hostid value. Your new machine is '12130954'. Your old machine is '12118165'. So you change 12130954 into 12118165.
* The 3rd edit is to prevent the old host ID from requesting new work. You just want to complete the 'lost tasks' when they are resent to you without getting any further tasks. To do this you need to insert the tag on a new line within the ... block towards the end of the block. I put it in immediately before the line that says .
* After checking your edits, save the file and exit the editor.
When you are ready, you can restart BOINC and it will read its ID from the state file and you shouldn't see any errors - you could get some minor complaints but I don't usually see any. I usually see an immediate contact with the server which results in a message of "Master file download succeeded" and that tells me all is well. In BOINC Manager you should notice that 'No New Tasks' is set. Please keep this set at all times, unless lost tasks are not being resent. I have a feeling that recent BOINCs might not get lost tasks if NNT is set. If you don't get the lost tasks, set the cache size quite low and enable work fetch to see if that's what is blocking things. For the BOINC versions I use (7.2.42) I get lost tasks when NNT is set.
Once your client contacts the scheduler (force with 'update' if necessary) you should get a response which corrects and fills in your skeleton state file and you should see messages about 'resending lost tasks'. All the data files for these tasks will need to be downloaded but I suspect the apps you currently have will be used and you won't be downloading the previous apps that were being used with the previous version of BOINC.
If all goes well and the lost tasks start crunching, just sit back and wait for them all to finish and be returned. You will then have an empty work cache (NNT still set) so just shut down your old ID for the last time and reverse the naming of the top directories. Just change (mv) boinc to boinc.old and then change boinc.save into boinc. You should then be able to start your latest host ID again from where it left off. If that all happens as per plan and your host has resumed crunching under the latest ID, just delete boinc.old at your convenience. In a reasonably short time (perhaps 1-2 weeks) all the completed tasks for your old ID will disappear from the online database. Then you should be able to merge the old ID into the new one.
Why bother? BOINC is designed for redundancy, those tasks will be re-issued to other hosts as needed to complete the quorum. That's a lot of work that will yield no more gain than if you'd just accepted new tasks.
* It can take up to 2 weeks for tasks to time out.
* It's a potentially quite useful skill to learn.
* It actually only takes a few minutes once you know what to do.
* You can do other quite useful things with the technique, other than just recovering stranded tasks on a defunct host.
* There's a certain satisfaction that comes from mastering techniques to resolve issues like this.
Some examples. During summer, sometimes heat-stressed hosts in my fleet experience a BOINC client failure in such a way that a critical data file is seen as corrupt (when it actually isn't) and all tasks that depend on that file are immediately marked as computation errors. Quite often the client goes into a 24 hour backoff with a cache full of these failed tasks. If you just 'update' to report all these and try to get new ones, you will likely be on a '1 task/day' allowance and have a lot of inconvenience as a result. You can actually use the technique to 'lose' all the failed results and have the server send them all back as 'lost tasks'. I have done this a multitude of times over the last few years.
I actually may need to use the basic technique in the near future for an entirely different reason. I have a host in my fleet that (for long and complicated reasons) managed to get itself into a state where its cache setting got to about 12 days at one point. The host is doing both BRP6 at 3x and FGRP4 on the CPU cores. Because of the oscillations in duration correction factor (DCF) caused by the out-of-sync eatimates of the two different task types, the actual on board GPU work exceeds the cache setting and will probably not be able to be completed before the various deadlines. There are a few hundred tasks on board and most will get done in time but my plan (for much nearer to the danger time - over a week from now) is to simply 'lose' the relatively few that would likely fail to be done on time and have the scheduler resend them with fresh deadlines. I've done this before when necessary. It takes just a couple of minutes and it works just fine. I also backup all the data files belonging to the results which are to be 'lost'. These files get deleted when BOINC restarts, without those results. I restore them before any scheduler contact so when the lost tasks are resent, the data will already exist and nothing needs to be downloaded.
At the end of the day, it's entirely up to the individual as to how much 'meddling' like this they want to get involved in. Nobody is being forced to take any notice of stuff like this if they don't feel competent to do so. If you want to just set and forget and let BOINC take care of itself, that's fine.
Merging accounts
)
If computers have same name. Sign into your e@h account. Click view at Computers on this account. Click show all computers. Then click on Merge computers by name. Should work.
Rob
No, it's not possible; unlike
)
No, it's not possible; unlike computers, accounts can't be merged.
Gruß
Gundolf
Computer sind nicht alles im Leben. (Kleiner Scherz)
Woops. My bad .Read to
)
Woops. My bad .Read to fast.
Rob (Slipping back into the shadows)
Thanks!
)
Thanks!
The only way I know of
)
The only way I know of keeping track of multiple accounts (e.g. credit sum) is to form a team of these.
BM
BM
I have 2 "compters" listed at
)
I have 2 "compters" listed at E@H. Their CPUs are identified as ARM and ARMv7 Processor rev 5 (v7l). Interesting listing since both are for the same Raspberry Pi2 B, but with different SD cards.
My original card failed, and I replaced it - had to do a reinstall and used a newer Raspi OS.
Is there any way to rename one of these so they can be merged? My interest is in recovering the 4 tasks that were in progress on the failed SD. Perhaps they can be re-acquired, but I see no option to allow me to request that.
Thanks.
RE: ... Interesting
)
The differences are probably due to the change from BOINC 7.0.27 --> 7.4.23. The newer BOINC probably detects the hardware more correctly.
For merging to work, you probably just need to wait for all tasks to disappear from the online database for the defunct host ID.
There isn't an option to do that but you can make it happen if you ask the scheduler nicely :-). You have to recreate the old host ID and the scheduler will respond to it and send the 'in progress' tasks as 'lost tasks'. Obviously you need to do this before the deadline - which starts 1st Dec.
I've done this many times before and it has always worked since Einstein has the option to 'resend lost tasks'. You just need to reinstate the old host ID and then contact the scheduler. Here are some detailed instructions. My BOINC tree starts at /home/gary/boinc/ - you just need to adjust paths for your situation.
* With the duplicate copy saved, you will now convert your current installation into one that is set up for your old host ID so that you can access the outstanding tasks there. NB: Don't touch anything in boinc.save. All edits are confined to the current tree and not the saved copy. To do this you need to find and edit (with a plain text editor) your state file client_state.xml. Essentially you will be deleting the bulk of the file between two particular editing points (inclusive).
* The first editing point is the line that immediately follows the closing tag. You are keeping the blocks for , , and and deleting what comes next. In my case that's an tag.
* The second editing point is about 10 lines from the end of the file. You will see a tag followed by stuff. The line immediately before this should be the closing tag for and this is the second edit point. You need to make all info about tasks, results, workunits, etc disappear so the scheduler will take pity on you and send all the correct info back to you. So just delete all lines between the two editing points inclusive, making sure you don't have any blank lines or disturbed formatting as a result of the deletions.
* In the stuff that is left, you need to make three further edits. The 1st edit is the value for . On your new ID it is currently '1' but it could have changed by the time you start to follow these instructions. On your old ID it is '24' and that shouldn't change. You need to increment it by one to '25' and insert this value for .
* The second edit is to change the hostid value. Your new machine is '12130954'. Your old machine is '12118165'. So you change 12130954 into 12118165.
* The 3rd edit is to prevent the old host ID from requesting new work. You just want to complete the 'lost tasks' when they are resent to you without getting any further tasks. To do this you need to insert the tag on a new line within the ... block towards the end of the block. I put it in immediately before the line that says .
* After checking your edits, save the file and exit the editor.
When you are ready, you can restart BOINC and it will read its ID from the state file and you shouldn't see any errors - you could get some minor complaints but I don't usually see any. I usually see an immediate contact with the server which results in a message of "Master file download succeeded" and that tells me all is well. In BOINC Manager you should notice that 'No New Tasks' is set. Please keep this set at all times, unless lost tasks are not being resent. I have a feeling that recent BOINCs might not get lost tasks if NNT is set. If you don't get the lost tasks, set the cache size quite low and enable work fetch to see if that's what is blocking things. For the BOINC versions I use (7.2.42) I get lost tasks when NNT is set.
Once your client contacts the scheduler (force with 'update' if necessary) you should get a response which corrects and fills in your skeleton state file and you should see messages about 'resending lost tasks'. All the data files for these tasks will need to be downloaded but I suspect the apps you currently have will be used and you won't be downloading the previous apps that were being used with the previous version of BOINC.
If all goes well and the lost tasks start crunching, just sit back and wait for them all to finish and be returned. You will then have an empty work cache (NNT still set) so just shut down your old ID for the last time and reverse the naming of the top directories. Just change (mv) boinc to boinc.old and then change boinc.save into boinc. You should then be able to start your latest host ID again from where it left off. If that all happens as per plan and your host has resumed crunching under the latest ID, just delete boinc.old at your convenience. In a reasonably short time (perhaps 1-2 weeks) all the completed tasks for your old ID will disappear from the online database. Then you should be able to merge the old ID into the new one.
Cheers,
Gary.
Why bother? BOINC is designed
)
Why bother? BOINC is designed for redundancy, those tasks will be re-issued to other hosts as needed to complete the quorum. That's a lot of work that will yield no more gain than if you'd just accepted new tasks.
Click Here to see My Detailed BOINC Stats
RE: Why bother? A
)
A number of reasons.
* It's a potentially quite useful skill to learn.
* It actually only takes a few minutes once you know what to do.
* You can do other quite useful things with the technique, other than just recovering stranded tasks on a defunct host.
* There's a certain satisfaction that comes from mastering techniques to resolve issues like this.
Some examples. During summer, sometimes heat-stressed hosts in my fleet experience a BOINC client failure in such a way that a critical data file is seen as corrupt (when it actually isn't) and all tasks that depend on that file are immediately marked as computation errors. Quite often the client goes into a 24 hour backoff with a cache full of these failed tasks. If you just 'update' to report all these and try to get new ones, you will likely be on a '1 task/day' allowance and have a lot of inconvenience as a result. You can actually use the technique to 'lose' all the failed results and have the server send them all back as 'lost tasks'. I have done this a multitude of times over the last few years.
I actually may need to use the basic technique in the near future for an entirely different reason. I have a host in my fleet that (for long and complicated reasons) managed to get itself into a state where its cache setting got to about 12 days at one point. The host is doing both BRP6 at 3x and FGRP4 on the CPU cores. Because of the oscillations in duration correction factor (DCF) caused by the out-of-sync eatimates of the two different task types, the actual on board GPU work exceeds the cache setting and will probably not be able to be completed before the various deadlines. There are a few hundred tasks on board and most will get done in time but my plan (for much nearer to the danger time - over a week from now) is to simply 'lose' the relatively few that would likely fail to be done on time and have the scheduler resend them with fresh deadlines. I've done this before when necessary. It takes just a couple of minutes and it works just fine. I also backup all the data files belonging to the results which are to be 'lost'. These files get deleted when BOINC restarts, without those results. I restore them before any scheduler contact so when the lost tasks are resent, the data will already exist and nothing needs to be downloaded.
At the end of the day, it's entirely up to the individual as to how much 'meddling' like this they want to get involved in. Nobody is being forced to take any notice of stuff like this if they don't feel competent to do so. If you want to just set and forget and let BOINC take care of itself, that's fine.
Cheers,
Gary.