I am uncertain as to the direction of the "merge" operation as it is implemented by BOINC or the web site or whatever.
If I have two stats entries for the same computer, let's say, entries "A" & "B", then I can request a merge from either one. If I choose incorrectly, then the two entries will soon re-appear as more results a reported.
If I go to entry "A" & request a merge, is my request interpreted as a request to merge "A" into "B" so that "A" disappears & does not re-appear so long as it is no longer reporting WUs? Or is my request interpreted as a request to merge "B" into "A"?
Thanks,
ADDMP
Copyright © 2024 Einstein@Home. All rights reserved.
Direction of Merge?
)
In an attempt to answer your question I'll post an email from the Dev's Mail List. The problem with same computer but different name may also be fixed in the near future.
See here for more: The boinc_dev Archives
Quote:
"Message: 2
Date: Thu, 07 Apr 2005 13:53:08 -0700
From: David Anderson
Subject: Re: [boinc_dev] Host id modification problem
To: Ian Hay
Cc: BOINC Development Mailing List
Message-ID:
Content-Type: text/plain; charset=us-ascii; format=flowed
Ian:
Thanks for pointing out and clarifying this problem.
I made a change based on your suggestion,
i.e. keep the old host records in the DB but have them
point to the new record. This is now deployed on
BOINC alpha test and SETI@home. Let me know if any problems.
checkin_notes entry:
David 6 April 2005
- Attempt to fix the situation where:
1) user merges hosts; hosts with lower IDs are folded
into host with maximal ID, then deleted
2) If host's client_state.xml file still has one of the
lower IDs, then the next time it contacts the scheduler,
the host lookup fails and a new host record is created,
which defeats the purpose of the merge.
Solution:
- When merge hosts, don't delete lower-ID records.
Instead, change them to "zombie" state, in which:
- userid is zero
- rpc_seqno is ID of new host record
- scheduler: if host is zombie, follow link to new host,
send back its ID to client "