In this case three fast responders got credit. The fourth, who received issue on 1 October, answered in less than 5 elapsed days but is deemed late (possibly this relates to the early date of original issue--13 Sep).
But that is the only one I currently see in this class.
I have two or three of these, for which the following seems to be true:
1. ABP2 10x WU
2. two results initially issued during the troubled period (e.g. 30 Sep)
3. one quick response
4. one slow response coming in for example 7 October.
5. currently the quick responder status is shown as "validation inconclusive"
6. currently the slow responder is shown as "validate error"
There are just enough of these last to make me a little suspicious--I normally have a very low rate of invalid. But by the same token, if there are very few, and associated with this event, not worth worrying about. I only mention because you mentioned interest in an example, and when I started typing Pete Burgess had not yet responded.
Here is one that contains two results that were "completed too late to vaildate". These two would have been the 'reissue tasks' as a result of both initial tasks being completed quickly and giving validate errors before anyone was actually aware of the problem. The full date range for the entire quorum of 4 tasks was from 30 Set to 05 Oct so no deadline was even remotely at risk.
EDIT: Here is yet another quorum containing 4 results, two of which were "completed too late to validate". This is a bit different again since one of the initial two that were returned very quickly (in fact the very first one to be returned) is one of those supposedly 'too late'. I haven't actually looked very far yet but I'm seeing quite a few of these 'too late - zero credits' results. I hope it's something simple to rectify.
The "too late" tasks are apparently a side effect of me messing around with transition and validation in order to fix the problem with the early ABP2x10 workunits. I now know how to avoid this for future re-validations.
In total there are 1807 tasks affected. I won't change the state of these tasks anymore, but will manually grant credit for them either today or early next week.
The "too late" tasks are apparently a side effect of me messing around with transition and validation in order to fix the problem with the early ABP2x10 workunits. I now know how to avoid this for future re-validations.
Dominoes. Well, we live and learn. Let's hope for no recurrence to provoke the need.
Quote:
In total there are 1807 tasks affected. I won't change the state of these tasks anymore, but will manually grant credit for them either today or early next week.
Sounds good to me. Outstanding effort Bernd. Well done! :-)
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
At the moment I am posting the server status pages lists 45064 ABP2 workunits awaiting validation as of an update at 7 Oct 2010 19:15:03 UTC. Watching that number decline is probably a useful index of progress at the project level on resolving this issue.
As of 8 Oct 2010 14:45:03 UTC the ABP2 workunits awaiting validation has dropped to zero. But I that is not yet the end.
As Bernd mentioned below
Quote:
As more and more results drop in on the wrong server and will be transferred to the correct one, some more rounds of re-validation will be necessary.
and progress in that process is not likely captured in simple observation of the status page "awaiting validation" number.
On my hosts, the current pending where at least two have returned results is utterly dominated by WU's set to the (21,-1) state, which Bernd has mentioned
Quote:
For workunits like this one (minimum quorum = 21) files are still missing on the right server.
The other major category of pending on my hosts is utterly normal--I've returned a result sooner than my current quorum partner. So despite a very small number of oddities, the general population seems to be behaving well.
But there will be a long tail of observable oddity. As Gary Roberts pointed out, some WUs generated new (excess) results sent out only a couple of days ago, and those won't go past deadline until sometime around October 20.
Hi Bernd, Try this one
)
Hi Bernd,
Try this one [url=http://einsteinathome.org/workunit/83920660[/url]
RE: That shouldn't happen.
)
one
In this case three fast responders got credit. The fourth, who received issue on 1 October, answered in less than 5 elapsed days but is deemed late (possibly this relates to the early date of original issue--13 Sep).
But that is the only one I currently see in this class.
Another possibly suspicious class is like this
I have two or three of these, for which the following seems to be true:
1. ABP2 10x WU
2. two results initially issued during the troubled period (e.g. 30 Sep)
3. one quick response
4. one slow response coming in for example 7 October.
5. currently the quick responder status is shown as "validation inconclusive"
6. currently the slow responder is shown as "validate error"
There are just enough of these last to make me a little suspicious--I normally have a very low rate of invalid. But by the same token, if there are very few, and associated with this event, not worth worrying about. I only mention because you mentioned interest in an example, and when I started typing Pete Burgess had not yet responded.
RE: That shouldn't happen.
)
I'm seeing these too.
Here is one that contains two results that were "completed too late to vaildate". These two would have been the 'reissue tasks' as a result of both initial tasks being completed quickly and giving validate errors before anyone was actually aware of the problem. The full date range for the entire quorum of 4 tasks was from 30 Set to 05 Oct so no deadline was even remotely at risk.
EDIT: Here is yet another quorum containing 4 results, two of which were "completed too late to validate". This is a bit different again since one of the initial two that were returned very quickly (in fact the very first one to be returned) is one of those supposedly 'too late'. I haven't actually looked very far yet but I'm seeing quite a few of these 'too late - zero credits' results. I hope it's something simple to rectify.
Cheers,
Gary.
The "too late" tasks are
)
The "too late" tasks are apparently a side effect of me messing around with transition and validation in order to fix the problem with the early ABP2x10 workunits. I now know how to avoid this for future re-validations.
In total there are 1807 tasks affected. I won't change the state of these tasks anymore, but will manually grant credit for them either today or early next week.
Edit: Done.
BM
BM
RE: The "too late" tasks
)
Dominoes. Well, we live and learn. Let's hope for no recurrence to provoke the need.
Sounds good to me. Outstanding effort Bernd. Well done! :-)
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: I now know how to
)
As more and more results drop in on the wrong server and will be transferred to the correct one, some more rounds of re-validation will be necessary.
BM
BM
RE: As more and more
)
Oh. OK. So the 'coherence' of result files b/w locations is still an issue? URL's, DNS or somesuch ?
Cheers, Mike.
( edit ) Forgive me. I haven't seen my emails for 14 hours and won't for another two. So I could have missed the mailing list updates ....
( edit ) Sorry. Silly me ... I've recalled the answer to that. Don't worry ... sigh, Friday is my 'long' day .... and I'm at the long end. :-)
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: At the moment I am
)
As of 8 Oct 2010 14:45:03 UTC the ABP2 workunits awaiting validation has dropped to zero. But I that is not yet the end.
As Bernd mentioned below
and progress in that process is not likely captured in simple observation of the status page "awaiting validation" number.
On my hosts, the current pending where at least two have returned results is utterly dominated by WU's set to the (21,-1) state, which Bernd has mentioned
The other major category of pending on my hosts is utterly normal--I've returned a result sooner than my current quorum partner. So despite a very small number of oddities, the general population seems to be behaving well.
But there will be a long tail of observable oddity. As Gary Roberts pointed out, some WUs generated new (excess) results sent out only a couple of days ago, and those won't go past deadline until sometime around October 20.