What is the easiest way to have a machine give up its ID without losing work and and have it obtain a new ID?

I suspect that is not possible so alternatively how can you make a machine give up its ID and then request a new ID without the dates overlapping even if any work you might be assigned is lost?

Since tasks are assigned to the computer id, which is assigned by the project changing the id would break the link to the tasks, which would be lost.

One has to ask "Why"?

If you substantially change the hardware (say go from an Intel CPU to an AMD CPU you will get a new id, but as for the tasks...

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

You can try changing rpc_seqno backwards:
http://asteroidsathome.net/boinc/forum_thread.php?id=475&postid=4656#4656

---

 


- ALF - "Find out what you don't do well ..... then don't do it!" :)
 

Without looking at the code again, getting a new ID assigned with task on the hostshould not be possible.

Hmm. Tricky one.

You have to convince the server it's looking at a new machine, so it doesn't reuse the current ID.
If you can get access to a non-cruncher, just for setup, and then transfer client_state.xml containing the fresh hostID to where you want a fresh Id ?

Fresh hostid fresh APRs...

I'd have to rewalk the code for further ideas on forcing a new hostID .

---

A person who won't read has no advantage over one who can't read. (Mark Twain)

You can try changing rpc_seqno backwards:
http://asteroidsathome.net/boinc/forum_thread.php?id=475&postid=4656#4656

Yes, that used to be the standard procedure, but host recognition has been tightened, so AFAIK it doesn't work any more.

---

A person who won't read has no advantage over one who can't read. (Mark Twain)

One has to ask "Why"?

In answer to your question, back in June for some unknown reason my Linux server picked up a new ID. When I realized it, I tried merging them so that I just had one machine again. The response I received was that I could not merge them because the dates overlapped. That was a real puzzler since it would have meant the server had two IDs at the same time. Since I did not think that was likely I assumed I was receiving that response because the times on the WUs overlapped. I then waited patiently for the all the WUs on the first ID to be completed. It has now been weeks since that happened and the first ID has absolutely no WUs of any sort and the earliest WUs on the second machine are dated way after the date of the split. Unfortunately that was not the answer as I still receive “overlapping lifetime” so I cannot merge them.

My current thought is that if I could create a new ID by design, and in such a manner that they don’t overlap, I can merge all three since the new ID would not overlap with the first one as well.

One has to ask "Why"?

In answer to your question, back in June for some unknown reason my Linux server picked up a new ID. When I realized it, I tried merging them so that I just had one machine again. The response I received was that I could not merge them because the dates overlapped. That was a real puzzler since it would have meant the server had two IDs at the same time. Since I did not think that was likely I assumed I was receiving that response because the times on the WUs overlapped. I then waited patiently for the all the WUs on the first ID to be completed. It has now been weeks since that happened and the first ID has absolutely no WUs of any sort and the earliest WUs on the second machine are dated way after the date of the split. Unfortunately that was not the answer as I still receive “overlapping lifetime” so I cannot merge them.

My current thought is that if I could create a new ID by design, and in such a manner that they don’t overlap, I can merge all three since the new ID would not overlap with the first one as well.

I had thought something similar in the past, but I was still not able to marge two hosts months after they had 0 tasks assigned to them. The time overlap seems to be recorded somewhere else. I believe the best you can hope for is the merging of ID 1 & 3. With the resulting ID being that of 3.

I have found it to be a bit more tricky getting the server to issue me a new ID more recently. Even when restoring an OS image that never had BOINC installed the server would assign the previous ID when I connected to the project. Unless I also changed the system name. Then I could change the system name back after to merge the host.
I was creating new IDs for benchmark/test use & then merging the previous into the last one when done.

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[

I had thought something similar in the past, but I was still not able to marge two hosts months after they had 0 tasks assigned to them. The time overlap seems to be recorded somewhere else. I believe the best you can hope for is the merging of ID 1 & 3. With the resulting ID being that of 3.

I have found it to be a bit more tricky getting the server to issue me a new ID more recently. Even when restoring an OS image that never had BOINC installed the server would assign the previous ID when I connected to the project. Unless I also changed the system name. Then I could change the system name back after to merge the host.

I was creating new IDs for benchmark/test use & then merging the previous into the last one when done.

Thanks for the hint on the system name. My last ditch effort, if there was no easy way forthcoming, was to be wait until I had no APs and very few MBs, kill boinc, move all the .xml and similar files to a new location, force a new IP address from my ISP by switching my ADSL modem from IPoE to PPPoE, and go from there. I would not have thought of changing the host name.

Two hosts have overlapping lifetime if one of the hosts has last contact time after the other has been created.

Using allow_multiple_clients with empty data directory should work too.

Two hosts have overlapping lifetime if one of the hosts has last contact time after the other has been created.

So it would appear. Apparently the SETI boinc server must have created a host ID before my machine knew about it and so it was still using the old ID. I am not sure how that would happen but that is the only explanation I can think of for overlapping times when only one machine is involved.

Using allow_multiple_clients with empty data directory should work too.

I had not heard of that parameter before but after doing a little research it seems that parameter is made for running two instances of boinc on the same host.

Based on that, I think what you are suggesting is that I do that and create ID#3 in that way so that I have ID#1 from the distant past, and ID#2 and ID#3 existing now on the same machine. What concerns me is that if ID#2 and ID#3 exist on the same machine at the same time, won't they for sure have overlapping times and therefore cannot be merged? I might merge #1 with #3 but won't there still be overlapping times when I try to merge afterwards with #2?

What I am not understanding?

If you can get access to a non-cruncher, just for setup, and then transfer client_state.xml containing the fresh hostID to where you want a fresh Id ?

Interesting thought, and that might be give me a new ID#3 but if I don't convince the SETI boinc server first that ID#2 is dead, won't I have overlapping times between ID#2 and ID#3? I guess I would have to make sure ID#2 has no work and then take it off line never to return before creating ID#3 with the non cruncher. Perhaps if I did that I could merge #1 and #3 immediately and then merge with #2 after all #2's pending WUs are completed and purged.

I have one question though. How close in hardware configuration does the non cruncher have to be to my current machine to be able to merge afterwards, or does the hardware difference matter at all?

If you can get access to a non-cruncher, just for setup, and then transfer client_state.xml containing the fresh hostID to where you want a fresh Id ?

Interesting thought, and that might be give me a new ID#3 but if I don't convince the SETI boinc server first that ID#2 is dead, won't I have overlapping times between ID#2 and ID#3? I guess I would have to make sure ID#2 has no work and then take it off line never to return before creating ID#3 with the non cruncher. Perhaps if I did that I could merge #1 and #3 immediately and then merge with #2 after all #2's pending WUs are completed and purged.

I have one question though. How close in hardware configuration does the non cruncher have to be to my current machine to be able to merge afterwards, or does the hardware difference matter at all?

By NO MEANS am I an expert... HOWEVER; earlier this year, I did a MAJOR hardware change on one of my systems. The existing OS threw a MASSIVE hissy fit and wouldn't boot.

The hardware change was "New"-Used MOBO with CPU, different BIOS, same case, same Kbd and Mse, same DVD-ROM, and HD, same GPU...

NOT wanting a new ID for BOINC, I bought a new HD, slaved the old HD, installed same OS on new HD, read and copied the data I wanted from old HD to the new drive; including the BOINC Folders. Upon bootup to Win 7 Pro Desktop, installed new BOINC over old BOINC, reinstalled Lunatics 0.43b, and FINALLY restarted the project and ALL WAS WELL - my existing ID stayed on the new hardware. With this done, and all data transferred, I formatted the old drive and gave it to a friend.

This was on my system I call Prometheus; which is now a QX9650 Core 2 Extreme Quad Core, on Gigabyte MOBO with DUAL BIOS, 8 GB RAM, and a GTX-750 TI SC. The MOBO has room for a second GTX-750 TI SC; but, right now I'm saving and raising donations to repair a broken tooth. So, it's going to be awhile longer than I had hoped to get a second GPU for this cruncher.

In the meantime, I still have Exeter with my GTX-760 that also crunches and is generating a good RAC combined with the work that Prometheus produces.

While this result is the opposite of what you want; it still shows that you can radically change hardware, and still have BOINC crunch on that system. I don't see why in setting up a neutral machine, (even with radically different hardware from the machine you want to change the ID on), that you couldn't get an ID for the neutral machine, and transfer it successfully to the old machine for your proposed ID #3.


TL

[EDIT:]

Just make sure you keep the Computer Name the same on each system.

---

TimeLord04
Have TARDIS, will travel...
Come along K-9!
Join Calm Chaos

If you can get access to a non-cruncher, just for setup, and then transfer client_state.xml containing the fresh hostID to where you want a fresh Id ?

Interesting thought, and that might be give me a new ID#3 but if I don't convince the SETI boinc server first that ID#2 is dead, won't I have overlapping times between ID#2 and ID#3? I guess I would have to make sure ID#2 has no work and then take it off line never to return before creating ID#3 with the non cruncher. Perhaps if I did that I could merge #1 and #3 immediately and then merge with #2 after all #2's pending WUs are completed and purged.

I have one question though. How close in hardware configuration does the non cruncher have to be to my current machine to be able to merge afterwards, or does the hardware difference matter at all?

If the hardware is different you will get the "No hosts are eligible for merging with this one." message. I wold hazard a guess the OS must match as well.

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[

Using allow_multiple_clients with empty data directory should work too.

I had not heard of that parameter before but after doing a little research it seems that parameter is made for running two instances of boinc on the same host.

Yes, and to make it work that parameter is passed to the scheduler so that it doesn't try find an older hostid but instead just creates a new one.

So run down the cache on ID2 (not strictly necessary but this way you don't have to rely on resend_lost_results being switched on), shutdown BOINC, delete or archive data directory, start BOINC with allow_multiple_clients and then re-add S@H. Now you should have ID3.

I have one question though. How close in hardware configuration does the non cruncher have to be to my current machine to be able to merge afterwards, or does the hardware difference matter at all?

Besides lifetime the other criteria is same OS name (Windows, Linux, Darwin, etc) and same CPU which is:

// Logic for deciding whether two host records might actually
// be the same machine, based on CPU info
//
// p_vendor is typically either AuthenticAMD or GenuineIntel.
// Over time we've changed the contents of p_model.
// Some examples:
// Intel(R) Core(TM)2 Duo CPU  E7300  @ 2.66GHz [Family 6 Model 23 Stepping 6]
// AMD Athlon(tm) II X2 250 Processor [Family 16 Model 6 Stepping 3]
// Intel(R) Xeon(R) CPU X5650 @ 2.67GHz [x86 Family 6 Model 44 Stepping 2]
// Intel(R) Core(TM) i5-2500K CPU @ 3.30GHz [Intel64 Family 6 Model 42 Stepping 7]
//
// in the last 2 cases, let's call x86 and Intel64 the "architecture"
//
// so, here's the policy:
//
// if p_ncpus different, return false
// if p_vendor different, return false
// if both have family/model/stepping info
//    if info disagrees, return false
//    if both have GHz info, and they disagree, return false
//    if both have architecture, and they disagree, return false
//    return true
// if p_model different, return false
// return true

Notice that whether the hosts have results or not is not a criteria. In fact, the code attempts to move results from old host to new host.

Notice that whether the hosts have results or not is not a criteria. In fact, the code attempts to move results from old host to new host.

Yeah it is a little odd when you have a host that spontaneously gets a new ID. The previously assigned tasks are listed under the old ID until they are returned. After being returned they are listed under the new ID. It makes sense, but just seems a bit odd the first time you actually see it.

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[

@Juha d'oh I completely forgot about that code path

---

A person who won't read has no advantage over one who can't read. (Mark Twain)

Using allow_multiple_clients with empty data directory should work too.

I had not heard of that parameter before but after doing a little research it seems that parameter is made for running two instances of boinc on the same host.

Yes, and to make it work that parameter is passed to the scheduler so that it doesn't try find an older hostid but instead just creates a new one.

So run down the cache on ID2 (not strictly necessary but this way you don't have to rely on resend_lost_results being switched on), shutdown BOINC, delete or archive data directory, start BOINC with allow_multiple_clients and then re-add S@H. Now you should have ID3.

With the recent splitter problems, my cache went to zero so I moved everything from the BOINC directory including the project sub-directories to a safe place. I then put all the boinc binaries back and created a new account_setiathome.berkeley.edu.xml along with new empty project sub-directories to replace the ones I moved. I next ran boinc with the --allow_multiple_clients switch and it crated a new ID. I was then able to merge all three IDs into the new one immediately. After that I put back the app_info.xml, and other needed files to make it crunch like ID#2. So far it seems to run fine. Thanks for your help and suggestions and thanks to everyone else who took the time to comment.