LHC@home

Peter was so kind to give me the fix for this bug in this post, and it works.

Thanks again, Peter. :-)

Yes it is good of Peter to spread the word around - but in fact it was posted on these boards in June by Steve Cressman

-- EDIT not in this thread but in another with a very similar name, here.

It must be time to start a new thread with the advice near the top so people notice it.

R~~

It must be time to start a new thread with the advice near the top

[Sticky] would be nice too :) If only a moderator was around...

---

A server side script can merge the ghosts with very few legit farms of identical machines getting crunched into 1 host.

The rule for merging is that the two hosts will be combined if
1) Their machine description is identical
2) The first date work is assigned & last date work is assigned or returned define a range that does not overlap.

If the date ranges for two hosts overlap then it will be very rare for one machine to be both hosts.
(I have had one machine connected as two seperate hosts each accepting work, so I know it's not impossible, just very rare :P )

Start with the first entry for each account and compare until all remaining hosts have been merged/rejected.
Repeat with next remaining host ignoring those that come earlier in list.
When done move to next account & repeat

Timing is similar to an optimized bubble sort, but that will be a concern only for accounts with large numbers of legit hosts. It is an algorithm that can be implemented with a fairly small amount of script code and allowed to run as a background batch job until done. This allows that old laptop that got 115 credits 2 yrs ago to remain & legit hosts with 0 credits will be unaffected unless they appear to be identical to another host on the same acct.

Of course the XML parser should be modified also to prevent a repeat, but even with the bug remaining, the script can be run once every few months to clean up the mess.

---

Is there a strong reason why, when merging hosts, they are merged to the highest number in the set instead of the lowest? I imagine that most of the time, particularly in this case when nobody ordered the higher numbers, retaining the lowest would be more user-friendly particularly if the earliest creation date were also retained.

---

Is there a strong reason why, when merging hosts, they are merged to the highest number ... .

The highest number most likely has received the latest
results, the lowest one should have delivered them all.

Merging is not only good for failures in the server
communication, it is good for merging a host that has
been reattached after some time of inactivity into his
previous self.

The reattached (highest) number has the latest stuff,
the previous installation nothing at all.


An option would have been, to make the server tell the
host about merging and new HostID on the next contact
but that is not implemented.

Sorry to be using an old post but just to show that not everyone here is
having problems.........

Problem is still happening! (and there is another thread about it)
This problem is making server load worse (host table in database is probably super-big by now) and also I think this is the reason why there are no stats. XML stats for hosts would be also extremely large.

Since there seems to be no post from someone _not_ experiencing the problem, I thought I'd point out that this not happening to everyone. It might be interesting to see if there are any patterns to the host duplication. . .

I have never had any of my hosts duplicated for no reason. My main host is using client Version 5.4.11 on windows xp. All of my hosts since the problem started have been windows of various versions.

I too have never had problems with duplicated hosts. My machine still contacts
LHC regularly to check for work and I have gone through all the client versions
of BOINC.

---