No. I was referring to the case 1.14/1.15/1.15/1.15 where the first 1.15 got marked as invalid (not inconclusive). If such a case exists...
I don't believe such a case would be possible because the first 1.15 could not be marked as invalid unless it really was.
I'm responding to myself in order to have Oliver's statement and my response to it.
I want to ask Oliver about something but not the situation he listed. This situation is a 1.14/1.14/1.15/1.15 quorum which I think is reasonably common. I just found one on the first machine I looked at. Here is the chronological sequence of events.
* Two 1.14 units are issued on 23rd Sept.
* One is returned quickly, the other times out on 7 Oct 7:11:15
* A 1.15 resend is issued 7 Oct 7:42:23 and returned 7 Oct 18:26:55
* As expected, the validator marks both (1.14 1.15) as inconclusive.
* A 2nd 1.15 resend is issued at 7 Oct 18:33:26.
* At 7 Oct 22:01:23 (a few hours later) the timed out 1.14 is returned and the quorum is completed with the first 1.15 being declared invalid.
* At 10 Oct 23:47:18 the final 1.15 was aborted before starting rather than being crunched and declared invalid.
The aborted task was mine and, without thinking further, I aborted it to prevent wasting the time on a task doomed to be invalid.
On reflection, I'm wondering if I should have allowed the task to crunch anyway. I certainly don't care about credit and the waste of electricity and cpu resources is not an issue if ultimately what Oliver's brief statements seemed to be implying comes to fruition.
So my question to Oliver is this. In quorums similar to this one where 2x1.15 were declared invalid because a 'resurrected' 1.14 was able to intervene and prevent a 1.15 to 1.15 comparison, will a subsequent action serverside be able to discard the two 1.14s and use the two 'invalid' 1.15s (if they are completed and agree) and so save any future action to reprocess that particular set of tasks? I'm concerned that my action in aborting my task may have actually caused the 'waste' of the crunched 1.15. I'm very happy to crunch a doomed 1.15 if I know it will be used later on. I'm sure every other concerned volunteer would be equally happy if this is the project's intention.
So my question to Oliver is this. In quorums similar to this one where 2x1.15 were declared invalid because a 'resurrected' 1.14 was able to intervene and prevent a 1.15 to 1.15 comparison, will a subsequent action serverside be able to discard the two 1.14s and use the two 'invalid' 1.15s (if they are completed and agree) and so save any future action to reprocess that particular set of tasks?
This workunit is an example of 2 x 1.14 invalidating 2 x 1.15 if you want to monitor if any serverside action is taken.
will a subsequent action serverside be able to discard the two 1.14s and use the two 'invalid' 1.15s (if they are completed and agree) and so save any future action to reprocess that particular set of tasks?
I don't think so, no. The "serverside action" would be focusing on credit only. We would expand the credit-fixup to include the case you just described such that 1.15ers would get credit even if two 1.14ers make up the valid quorum (in a mixed WU).
Scientifically it doesn't matter for us whether the canonical result of such a mixed 1.14/1.15 workunit was computed by the 1.14 app or the 1.15 app because we won't take any chances there and will treat those like a 1.14-only WUs anyway.
FYI, we ran the first round of credit fix-ups. We'll repeat it this Friday as well as Friday next week (remember, the 1.14 deadline expires this Wednesday).
It means that if anybody has an unstarted resend in an already completed quorum, then it may as well be aborted. Completing it wont add anything to the science but aborting it will allow something more useful to be done with the resources.
It's very easy to spot resends (_2 or higher suffixes, or even an 'old' data file number in the name) and then a quick check to see if it's already got a canonical result or not.
RE: RE: No. I was
)
I'm responding to myself in order to have Oliver's statement and my response to it.
I want to ask Oliver about something but not the situation he listed. This situation is a 1.14/1.14/1.15/1.15 quorum which I think is reasonably common. I just found one on the first machine I looked at. Here is the chronological sequence of events.
* One is returned quickly, the other times out on 7 Oct 7:11:15
* A 1.15 resend is issued 7 Oct 7:42:23 and returned 7 Oct 18:26:55
* As expected, the validator marks both (1.14 1.15) as inconclusive.
* A 2nd 1.15 resend is issued at 7 Oct 18:33:26.
* At 7 Oct 22:01:23 (a few hours later) the timed out 1.14 is returned and the quorum is completed with the first 1.15 being declared invalid.
* At 10 Oct 23:47:18 the final 1.15 was aborted before starting rather than being crunched and declared invalid.
The aborted task was mine and, without thinking further, I aborted it to prevent wasting the time on a task doomed to be invalid.
On reflection, I'm wondering if I should have allowed the task to crunch anyway. I certainly don't care about credit and the waste of electricity and cpu resources is not an issue if ultimately what Oliver's brief statements seemed to be implying comes to fruition.
So my question to Oliver is this. In quorums similar to this one where 2x1.15 were declared invalid because a 'resurrected' 1.14 was able to intervene and prevent a 1.15 to 1.15 comparison, will a subsequent action serverside be able to discard the two 1.14s and use the two 'invalid' 1.15s (if they are completed and agree) and so save any future action to reprocess that particular set of tasks? I'm concerned that my action in aborting my task may have actually caused the 'waste' of the crunched 1.15. I'm very happy to crunch a doomed 1.15 if I know it will be used later on. I'm sure every other concerned volunteer would be equally happy if this is the project's intention.
Cheers,
Gary.
RE: So my question to
)
This workunit is an example of 2 x 1.14 invalidating 2 x 1.15 if you want to monitor if any serverside action is taken.
Hi Gary, even without
)
Hi Gary,
even without canceling such a WU I noticed a couple of this Constallation, in my meanwhile 23 Invalids, where I was the 1.15 Part.
Greetings
DMmdL
Greetings from the North
Hi Gary, RE: will a
)
Hi Gary,
I don't think so, no. The "serverside action" would be focusing on credit only. We would expand the credit-fixup to include the case you just described such that 1.15ers would get credit even if two 1.14ers make up the valid quorum (in a mixed WU).
Scientifically it doesn't matter for us whether the canonical result of such a mixed 1.14/1.15 workunit was computed by the 1.14 app or the 1.15 app because we won't take any chances there and will treat those like a 1.14-only WUs anyway.
HTH,
Oliver
Einstein@Home Project
FYI, we ran the first round
)
FYI, we ran the first round of credit fix-ups. We'll repeat it this Friday as well as Friday next week (remember, the 1.14 deadline expires this Wednesday).
Oliver
Einstein@Home Project
RE: HTH, Oliver Sure
)
Sure does.
It means that if anybody has an unstarted resend in an already completed quorum, then it may as well be aborted. Completing it wont add anything to the science but aborting it will allow something more useful to be done with the resources.
It's very easy to spot resends (_2 or higher suffixes, or even an 'old' data file number in the name) and then a quick check to see if it's already got a canonical result or not.
Thanks for the clarification.
Cheers,
Gary.