Can an admin fix the CPU description of a machine of mine?
14 Jan 2016 5:46:50 UTC
Topic 198374
(moderation:
My old https://einsteinathome.org/host/6239794 is listed as "GenuineIntel Intel(R) Core(TM) i7-3770S CPU @ 3.10GHz [Family 6 Model 58 Stepinng9]]" which is clearly a bad spelling. I have no idea how that spelling got into the database. But that machine is re-setup with newer OS etc., and the new one https://einsteinathome.org/host/12167181 is listed correctly as "GenuineIntel Intel(R) Core(TM) i7-3770S CPU @ 3.10GHz [Family 6 Model 58 Stepping 9]". Due to the mismatch, I cannot merge the former into the latter. I am hoping that this misspelling is fixable by an admin so that I can execute a merge on it.
Thanks
Tuna
Can an admin fix the CPU description of a machine of mine?
)
The old version of the BOINC server software (which ran for a long period at this project) used to allow quite a bit of latitude in the selection of hosts that could be merged. From memory you were just asked to specify the hostID you wanted the current host to merge with. This software got upgraded quite recently so I tried a merge operation on one of my hosts only to be advised that there were no suitable hosts for the operation. I hadn't done a merge for many years so I wanted to see what would happen these days.
I noticed there was a 'details' link along with the "No suitable hosts" message, so I clicked that wondering what the details might be. It was a long list of all other computers on my account with a reason why each one was 'unsuitable'. By chance, the host I selected for this test was one that dated back to 2005 when I first joined the project. The most common reason by far why all other hosts were being rejected was something to the effect of "overlapping date periods". Of course, a hostID (not the same physical machine) having a continuous attach period from 2005 to present, is really going to rule out all other machines in my complete list.
I sincerely hope that a mere spelling error like the one you show couldn't prevent the merge. Surely the rules aren't that strict. Did you by any chance click the 'details' link that appears to look at the precise reason given for not allowing a merge? I assume you went to the host details page for hostid=6239794 and clicked the 'merge' link. The result would have been a new page saying there were no other hosts suitable for the operation. If you click the 'details' link there, it should provide a list of your other hosts that were checked and the reason why each was unsuitable. It would be interesting to see the reason given for why 12167181 was unsuitable. Surely, it wasn't just because Stepinng doesn't agree with Stepping? :-).
Cheers,
Gary.
Hi Gary. Sadly, that seems
)
Hi Gary.
Sadly, that seems to be exactly the reason. I actually clicked on 12167181 and then MERGE since this one is the current host that should swallow the old credits. And, the details as to why that wouldn't be kosher is the CPU:
Host 6239794 has an incompatible CPU: (GenuineIntel Intel(R) Core(TM) i7-3770S CPU @ 3.10GHz [Family 6 Model 58 Stepping 9], GenuineIntel Intel(R) Core(TM) i7-3770S CPU @ 3.10GHz [Family 6 Model 58 Stepinng9]])
I had looked at the Details of why the merge was not allowed before posting my question. I just merged this new computer with all of its older incarnations at about 50 different BOINC project sites, using the exact same method, and they all had the new server software, giving me options as to which old computers were eligible. I was not able to succeed only at two projects: Einstein and Leiden. Here, only the old host has the misspelling. At Leiden, BOTH have the exact same misspelling, yet DETAILS claims they are not compatible due to CPU. I also posted a question there. Given that at Leiden I get a CPU incompatibility even though the misspellings match, I started wondering if it is not just the misspelling, but the fact that there is a double-bracket at the end of at least one of the CPU names, and somehow the CPU-name-parsing-code gets confused by that, returns ERROR, which escalates into a NOMATCH.
Do you or another admin have the ability to fix that one string in the database and then I can retry to see if that was the problem?
Thanks
Tuna
Done! Happy
)
Done! Happy merging...
Oliver
Einstein@Home Project
Awesome! They merged now! Me
)
Awesome! They merged now! Me so happy... :-) Now I can go to bed.
Only if Leiden admins were as responsive... I have not much expectation from them, looking at their Forum activity. Bummer.
Thanks!!!
Tuna
You're welcome :-D
)
You're welcome :-D
Einstein@Home Project
The issue I run into most
)
The issue I run into most often is when doing a complete wipe and install of a new operating system; whether it be changing from Windows to Linux, or even installing a new major version of Windows. One workaround I've found is to do an upgrade first so that the host gets updated with the version change (though not possible with switching to/from Linux) and then do a wipe/install. Otherwise, you'll end up with hosts that are identical in hardware but are not mergeable to BOINC because the operating systems are stated as incompatible.
And then there is the (one) project that doesn't have provision for merging hosts of any kind... It knows who it is.
Click Here to see My Detailed BOINC Stats
RE: And then there is the
)
Wrong! Two projects. :-)
And, I'll name names: Gerasim@Home. World Community Grid.
Yeah, I went through them all last night.
Can you subvert merging
)
Can you subvert merging restrictions by editing the hostid in one of the client state files?
I have a vague recollection of doing something like that years ago.
Ooooohhhh.... Smells
)
Ooooohhhh.... Smells dangerous... :-)
RE: Can you subvert merging
)
There aren't two state files here. The old installation is gone. The machine has been reinstalled. The only thing available to edit is the current hostID and if that were changed back to the old value I imagine that would create issues at the server end (two IDs for the same hardware). At best, the server might activate the old dormant ID, leaving the current ID in limbo land. At worst, the server may detect the two IDs and so retire both of them and allocate a new unique ID to resolve the problem before proceeding. This is just guesswork but I wouldn't be game enough to give it a try to find out :-).
What can be done is to tell BOINC before a new ID is allocated that the new install will be using the previous ID for a host that no longer exists. That way there is no chance of a double-up in the IDs. This can be done by 'seeding' the install tree with a template state file that contains .... blocks with just the critical information before BOINC is installed on the user machine. You would need these blocks for each separate project on which you wanted to retain the hostID. There are very few lines that are critical so the template can be quite small. When the client contacts the server, the exchange between the two allows all the missing details (other than the supplied critical stuff) to be filled in so that a proper state file is created. This all has to be done beforehand. Once a new ID is issued, merging is the only option to combine them.
I know this works because I've done it many times. All the IDs I had back in 2005 when I first started are still active today, albeit in completely different hardware :-). When I decide to add a new host, I just give it the ID of a retired one.
Cheers,
Gary.