Hummmmm. 125 Valid. 50 Waiting for validation now. Why is that? Is My connection dropping out?
T'is all fine. You have a fast turnaround with your rigs. They are awaiting the 'wingmen' to report back for each work unit ( if you compare your validated tasks with those not yet validated, the wingman is 'In progress' with the latter ). We send a given work unit out to several hosts, with a 2 week timeout for no-show, and validation awaits ( currently quorum size is : ) two hosts to report back.
As you've been crunching for a little over 2 weeks now, either the initial ( onwards from 17/10/2010 ) wingmen have reported back, or failing that there has been a re-issue to other hosts. Depends on the activity of the host milieu as we cross-check each other's work using machines of widely varying capability.
There's always going to be a fraction of your work awaiting validation, and the more so if you are especially quick compared to other hosts. I can't see any WU's either in 'error' or 'invalid' for your machines. :-)
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
And I have around 180 pending with Pending credit: 16,432.54, as Mike said it is normal, we must wait for others to crunch their half of our units before the credits are granted. Then of course if they have problems we have to wait even longer, it is the nature of the game.
Actually I reckon there's several likely reasons for having a higher pending list if you have a fast machine. One is that the machine goes through quite a few WU's in the first place, so one's personal data pipeline has larger capacity/throughput. The other is, as mentioned, that the wingman is likely to be of lesser performance if one is of rather higher than average performance. The third is a softer correlation, but I think is true, that being people with higher performing machines also have higher internet bandwidth available ( both are economically linked ) - and hence more likely to be using the 'always on' network preference, so that has a mild tendency to reduce the time to report back upon completion too.
Consider my best machine, which is #239 on the top hosts list ie. in the upper ~0.2% of currently active hosts - so >99% of machines are less active, but not necessarily of lesser performance depending upon how E@H is allocated ( other BOINC projects, activity settings etc ). It has ~ 80 pending, generally back to about 2 weeks ago ( ie. the timeout threshold ) and the current oldest is initially from 01/10/2010 which has undergone two re-issues. For that one I'm waiting on others, possibly until 21/11/2010 - or even later if a wingman falls over again. The first wingman had a whole raft of user initiated aborts - on the face of it a tendency to cherry pick for CUDA ABP's, but may well be due to our validator troubles, or some other circumstance [ whoever you are feel free to enlighten me here! :-) :-) ]
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
I think you also see the phrase "Aborted by user" on the website if a computer is switched off for an extended period, and then turned back on after the task deadlines have passed. In that case it's the BOINC client, rather than the user him or her self, which initiates the aborts for work past deadline but not yet started. Looking at the list you've linked, I think that's probably more likely in this case - no sign of cherry-picking there.
I think you also see the phrase "Aborted by user" on the website if a computer is switched off for an extended period, and then turned back on after the task deadlines have passed. In that case it's the BOINC client, rather than the user him or her self, which initiates the aborts for work past deadline but not yet started. Looking at the list you've linked, I think that's probably more likely in this case - no sign of cherry-picking there.
Agreed! Which is precisely why I carefully phrased 'on the face of it ..... but ...... or .....' and suggested alternates, so that others wouldn't un-necessarily jump to the wrong conclusion! ( and generate offense where none is deserved ). That WU is a good example of how one's own validation can be delayed significantly by factors outside a given user's control. :-)
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
The latest I've heard was taht it still needed a few weeks of dev labor before deployment; but that their devs were all occupied with more important stuff.
Curious...
)
T'is all fine. You have a fast turnaround with your rigs. They are awaiting the 'wingmen' to report back for each work unit ( if you compare your validated tasks with those not yet validated, the wingman is 'In progress' with the latter ). We send a given work unit out to several hosts, with a 2 week timeout for no-show, and validation awaits ( currently quorum size is : ) two hosts to report back.
As you've been crunching for a little over 2 weeks now, either the initial ( onwards from 17/10/2010 ) wingmen have reported back, or failing that there has been a re-issue to other hosts. Depends on the activity of the host milieu as we cross-check each other's work using machines of widely varying capability.
There's always going to be a fraction of your work awaiting validation, and the more so if you are especially quick compared to other hosts. I can't see any WU's either in 'error' or 'invalid' for your machines. :-)
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
66 pending... dunx
)
66 pending...
dunx
RE: 66 pending... dunx
)
And I have around 180 pending with Pending credit: 16,432.54, as Mike said it is normal, we must wait for others to crunch their half of our units before the credits are granted. Then of course if they have problems we have to wait even longer, it is the nature of the game.
Actually I reckon there's
)
Actually I reckon there's several likely reasons for having a higher pending list if you have a fast machine. One is that the machine goes through quite a few WU's in the first place, so one's personal data pipeline has larger capacity/throughput. The other is, as mentioned, that the wingman is likely to be of lesser performance if one is of rather higher than average performance. The third is a softer correlation, but I think is true, that being people with higher performing machines also have higher internet bandwidth available ( both are economically linked ) - and hence more likely to be using the 'always on' network preference, so that has a mild tendency to reduce the time to report back upon completion too.
Consider my best machine, which is #239 on the top hosts list ie. in the upper ~0.2% of currently active hosts - so >99% of machines are less active, but not necessarily of lesser performance depending upon how E@H is allocated ( other BOINC projects, activity settings etc ). It has ~ 80 pending, generally back to about 2 weeks ago ( ie. the timeout threshold ) and the current oldest is initially from 01/10/2010 which has undergone two re-issues. For that one I'm waiting on others, possibly until 21/11/2010 - or even later if a wingman falls over again. The first wingman had a whole raft of user initiated aborts - on the face of it a tendency to cherry pick for CUDA ABP's, but may well be due to our validator troubles, or some other circumstance [ whoever you are feel free to enlighten me here! :-) :-) ]
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
I think you also see the
)
I think you also see the phrase "Aborted by user" on the website if a computer is switched off for an extended period, and then turned back on after the task deadlines have passed. In that case it's the BOINC client, rather than the user him or her self, which initiates the aborts for work past deadline but not yet started. Looking at the list you've linked, I think that's probably more likely in this case - no sign of cherry-picking there.
RE: I think you also see
)
Agreed! Which is precisely why I carefully phrased 'on the face of it ..... but ...... or .....' and suggested alternates, so that others wouldn't un-necessarily jump to the wrong conclusion! ( and generate offense where none is deserved ). That WU is a good example of how one's own validation can be delayed significantly by factors outside a given user's control. :-)
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
Thanks for the info... I
)
Thanks for the info... I can't say I let BOINC activity worry me, I let work do that !
LOL
dunx
P.S. I had to abort some tasks due to a SATA problem - overheating Southbridge... Shame ! Now has it's own 80mm fan.
P.P.S. Any news on the greatly anticipated CUDA upgrade work ?
The latest I've heard was
)
The latest I've heard was taht it still needed a few weeks of dev labor before deployment; but that their devs were all occupied with more important stuff.