I'm My Own Grandpa ... umm ... Wingman!
31 Aug 2015 18:15:54 UTC
Topic 198214
(moderation:
While looking to see what was holding up credit for task PM0049_02191_300_0 which my i7-860 completed on 30 Aug, I was surprised to see that the other half of the quorum, PM0049_02191_300_1, was assigned to my Q9550! (see http://einsteinathome.org/workunit/225909288)
Question: How common is it that "I'm my own wingman?" (to the tune of the Ray Stevens classic "I'm my own Grandpa" https://www.youtube.com/watch?v=zeIsxXDyjlc.)
And, what external factors enhance the likelihood?
Stan
I'm My Own Grandpa ... umm ... Wingman!
)
That's not normal across Boinc!! Projects tend to stay away due to one user having a batch of bad pc's affecting the outcomes.
RE: RE: While looking to
)
I think the original reason for avoiding it was to reduce the possibility of fraud.
David
Miserable old git
Patiently waiting for the asteroid with my name on it.
RE: I think the original
)
From the font of boinc there are two server side settings...
If set, send at most one instance of a given job to a given user. This increases the effectiveness of replication-based validation by making it more difficult for hackers to get all the instances of a given job.
If present, send at most one result of a given workunit to a given host. This is weaker than one_result_per_user_per_wu; it's useful if you're using homogeneous redundancy and most of the hosts of a particular class belong to a single user.
Which may suggest only the second is set.
Thank you, Gents.
)
Thank you, Gents.
AgentB, interesting about the project option. So E@h explicitly allows it.
Then increasing the number of one's hosts would increase the probability of occurrence ... proportional to (nhosts-1)?
Updating multiple hosts (requesting tasks) at the same time, e.g. by the 'update' tool in BoinkTasks, would move the probability off "virtually zero" toward "will happen once in a while"? This would seem an almost necessary precondition, I think, since I understand that all members of a quorum become available for assignment at the same time.
Stan
We definitely set . This
)
We definitely set .
This is a serious error.
Thanks for pointing it out.
BM
BM
FWIW we currently have 729
)
FWIW we currently have 729 such WUs in the DB, with 900k WUs in total the chance of this happening is <0.1%.
Yet still this is enough to worry me, as this should never ever happen.
BM
BM
RE: While looking to see
)
Interestingly both tasks were sent at exactly the same time, 22 Aug 2015 20:17:23 UTC.
RE: RE: While looking to
)
[Thinking out loud] Hmmmm .... the second one is sent/allocated before the first is marked in the DB ? If so the "same user" test on the second task is being applied before the DB is updated with the allocation of the first. With asynchronous processes - here task allocation & DB marking - this could happen depending on any delay in the backends. If that's so, you'd need to have a sequence point set to await resolution/confirmation before proceeding with the next host assignment. Or just remember the very last user ID assigned, but that would not catch a next-to-last inconsistency ( or next-to-next-to-last ....). What a pain.
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
RE: RE: RE: While
)
Hmm, it's not that you have to compare userids, you just have to ensure a division, so something like (for quorum=2) odd numbered userids can only be given odd tasks, and even, even numbered tasks.
Edit: i guess there's a reasonable assumption that task-id are sequential, and user-id are randomly and evenly spread.
The problem has been tracked
)
The problem has been tracked down, and the fix is easier to implement than I first thought.
I won't reveal the details here, though, until I implemented it, to avoid attracting cheaters.
It is usually a bad idea to change the scheduler on a Friday, so I'll wait until Monday.
Thanks again for reporting!
BM
BM