![]() |
[QUOTE=kriesel;524097]exponential decay[/QUOTE]
:shock: haha, what the exponential has to do here? If the guy has some resources to clean one exponent per day (or week, month) then he will still do so forever, regardless of how much work he has queued, his "productivity" (well, what is the antonym of productivity? stagnantivity? hehe) is not a percent of the work he has queued. This is just a "linear decay" :razz: If I reserve 100 exponents and I can clean 10 per period (day, week, month, etc), this will take 10 periods, and not 44 periods (like in exponential decay of 10%). |
I guess that sometimes my interest in monitoring progress around so called milestones is mistaken as impatience.
Nothing further from the truth. I am very conscious that the completion of milestones is never urgent and that the world won't be engulfed into an exploding Sun or become a tetrahedron if a particular milestone is not met in a two days, a week or a year. (I would even expand that time frame to a millenium). To me, milestones are just that, little markers on a road that indicate us how far we have travelled and how much more we need to travel to get to a point in our path. I would much prefer fewer and more significant stones like every 10 or 5 million increases, and every time all exponents below a mersenne prime is tested at least once or when verified by a second test making it officially the Nth mersenne prime, but I can understand why others look at more frequent milestones (with 1 million spacing) as something desirable. I just have the feeling that this can improve and that is all there is to it. |
[QUOTE=LaurV;524100]:shock: haha, what the exponential has to do here? If the guy has some resources to clean one exponent per day (or week, month) then he will still do so forever, regardless of how much work he has queued, his "productivity" (well, what is the antonym of productivity? stagnantivity? hehe) is not a percent of the work he has queued. This is just a "linear decay" :razz: If I reserve 100 exponents and I can clean 10 per period (day, week, month, etc), this will take 10 periods, and not 44 periods (like in exponential decay of 10%).[/QUOTE]Linear or exponential are only models for what's actually going on. "a rough extrapolation"
Exponential gave ~6 months to the last remaining exponent, linear would have given about 1.5 months. Patgie has been observed to lose a small percentage of expired assignments to other users at each expiration/renewal cycle, and also to finish some. There's an assumption in your linear rate, Laurv, that I think eventually fails. You won't perform 10 per period if it takes n>=1 period to do a full run and you only have 9 or fewer exponents to run. If patgie had enough throughput to finish in 10 cycles, he'd be done now. (Count the expirations per exponent.) Throughput in the exponent range of interest (in this case 85-86M) is not maintained at a constant number of primality tests per period if one drops to fewer assignments in the exponent interval of interest, than hardware units to run them on, and the rest of the available throughput is applied to higher exponents to keep the rest of the hardware fleet of the user from being idle. No one can run 16 systems on the last first-test exponent assigned, to spit out the last assigned exponent at the same throughput rate as when much of their whole fleet is running separate exponents in the range of interest. (I need dozens of assignments running in parallel, or throughput drops due to idle hardware, and there are other users that need more. Configuring for max throughput per system increases the numbers higher, due to multi-cpu-package systems with separate caches and NUMA, and mid to high performance gpus needing sometimes 2 or three instances each to maximize throughput.) Only a tiny fraction <5% of my total throughput is going toward my last 3 first-PRP assignments <86M, and an even tinier fraction of curtisc's for his remaining LL tests <86M. |
All tests below 48 million verified.:smile:
|
So, I've had number of my LL checks turned into Ds now after I've invested quite a bit of cycles. The latest was [M]85970561[/M] where the server gave it to me, but then patgie submitted a result after it was expired. That's pretty annoying. If mine wasn't so far along, I would just unreserve. From now on I'll unreserve any assignments that patgie has touched.
|
And that is why poachers are not well liked.
|
[QUOTE=Uncwilly;525280]And that is why poachers are not well liked.[/QUOTE]
Yep. Some of my machines were fast enough to finish in a day or so and win, but this one landed on one that was too slow and lost the race. |
[QUOTE=mrh;525284]Yep. Some of my machines were fast enough to finish in a day or so and win, but this one landed on one that was too slow and lost the race.[/QUOTE]It isn't a race. Both results are needed. No cycles have been wasted.
|
[QUOTE=retina;525287]It isn't a race. Both results are needed. No cycles have been wasted.[/QUOTE]
sure it is! one person gets credit for being first and the other doesn't. it's friendly and doesn't mean anything, but it's a race. makes it fun. :grin: |
There are 3 assignments
[code] 85526383 LL LL, 10.80% [COLOR="Red"]3[/COLOR] 8 2019-07-12 2019-10-07 2019-10-08 2019-10-15 c0nd0r 85767821 LL LL, 93.30% [COLOR="Red"]1 -16[/COLOR] 2019-09-08 2019-09-20 2019-09-21 2019-09-21 OscarX 85925303 LL LL, 63.70% 36 12 2019-08-14 2019-10-07 2019-10-08 2019-10-19 Michael Quevillon[/code] All three are stuck there for 5 days already. (No, I am not advocating poaching) |
[QUOTE=rudy235;527471]There are 3 assignments
[code] 85526383 LL LL, 10.80% [COLOR="Red"]3[/COLOR] 8 2019-07-12 2019-10-07 2019-10-08 2019-10-15 c0nd0r 85767821 LL LL, 93.30% [COLOR="Red"]1 -16[/COLOR] 2019-09-08 2019-09-20 2019-09-21 2019-09-21 OscarX 85925303 LL LL, 63.70% 36 12 2019-08-14 2019-10-07 2019-10-08 2019-10-19 Michael Quevillon[/code] All three are stuck there for 5 days already. (No, I am not advocating poaching)[/QUOTE] As I read it 1st and 3rd are current. The middle one is 17 days late. |
| All times are UTC. The time now is 22:37. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.