Newer milestone thread

[rudy235]

Originally Posted by dcheuk

Thanks for the clarification.

Was curious, if someone was doing say an LL and then the assignment expires and was assigned to someone that does a PRP test. That would be a huge waste if the original user was at like 90% or something.

YES, assuming both are completed, the third check would have to match one of the previous 2 to be considered a DC.
Preferably the user that is beginning the PRP might be wise to abandon his/her assignment and start a LL test if possible.

[dcheuk]

Originally Posted by rudy235

Preferably the user that is beginning the PRP might be wise to abandon his/her assignment and start a LL test if possible.

It would be nice if the server automatically assigns the same kind of test if expired with significantly progress, since the end user would likely be unaware a different test is almost complete but expired.

But it's probably pretty rarely, one would hope.

[rudy235]

Three additional exponents have been completed.

83556937	PRP     2019-04-11              Kriesel
83902069	PRP	2019-03-04		Kriesel
83998979	LL      2019-03-11	        Juampa

16 to go.

[Madpoo]

Originally Posted by dcheuk

It would be nice if the server automatically assigns the same kind of test if expired with significantly progress, since the end user would likely be unaware a different test is almost complete but expired.

But it's probably pretty rarely, one would hope.

It's not a bad idea - the server would need to take into consideration whether or not the previous assignee was actually working on the exponent, albeit very slowly. Or if the assignee had just given up.

That's the kind of thing that we can eyeball and see that "hey, user xyz hasn't reported any progress on that assignment in xx days - they've probably given up or their machine died". So that's easy enough.

It's the other case when a machine is reporting in every few days, and then we'd have to see if they've actually moved the needle or not since the last time. There are still weird cases of a machine that somehow stalls. It reports in every day, but the % done is the same as the day before. This can go on for weeks or months before the user notices or reboots the machine or whatever.

The server doesn't natively keep a history of progress, although I did setup a system that logs the progress on a daily basis so I can run reports on the sluggards. It's just not "official".

In the meantime, if I spot a close race between expiration and completion, and I have a good indication the user is actually trying but will still miss it by a day or two (looking at you kriesel, LOL) then I can manually 'extend' the expiration by a day or two. I do that by simply adjusting when it was assigned... brute force, but it works.

The only reason for doing that is to avoid the kind of problems you point out, where it might get reassigned as PRP when the first test was LL, or just when it really will finish long before the new assignee has a chance of completing it, so it's really not fair to the new assignee to get "poached" like that, in a sense.

I'll take a look at the current queue in the milestones coming up and see if any adjustments are appropriate.

[kriesel]

Originally Posted by Madpoo

In the meantime, if I spot a close race between expiration and completion, and I have a good indication the user is actually trying but will still miss it by a day or two (looking at you kriesel, LOL) then I can manually 'extend' the expiration by a day or two. I do that by simply adjusting when it was assigned... brute force, but it works.

The only reason for doing that is to avoid the kind of problems you point out, where it might get reassigned as PRP when the first test was LL, or just when it really will finish long before the new assignee has a chance of completing it, so it's really not fair to the new assignee to get "poached" like that, in a sense.

I'll take a look at the current queue in the milestones coming up and see if any adjustments are appropriate.

Or if a conscientious participant says, hey, it's not fair to the next assignee, please extend it to avoid expiration and reassignment and I'll finish what I was assigned for efficiency. It's not poaching to finish a legit assignment that's _ALMOST THERE..._ and save the project cpu-weeks or gpu-days or weeks. It's more along the lines of setting the unsuspecting new assignee up to fail, to assign him such an exponent that will soon complete elsewhere.

It's good to have someone at the helm doing the sensible thing in such cases.

[rudy235]

13 to go.

There are 13 assignments

83599379	LL		6	9	2019-05-17	2019-05-17	2019-05-18	2019-05-27	bwrede
83676167	LL	LL, 6.00%	27	11	2019-05-15	2019-05-18	2019-05-19	2019-05-29	Yoon
83732731	LL	LL, 27.30%	23	3	2019-05-11	2019-05-17	2019-05-18	2019-05-21	ATH
83732989	LL	LL, 75.40%	3	-20	2019-02-22	2019-04-21	2019-04-22	2019-04-28	Nonickname
83766227	LL	LL, 60.40%	7	-1	2019-02-24	2019-05-10	2019-05-11	2019-05-17	Will Hockensmith
83768717	LL	LL, 28.70%	7	32	2019-02-24	2019-05-14	2019-05-15	2019-06-19	curtisc
83802931	LL	LL, 58.20%	9	4	2019-02-26	2019-05-17	2019-05-18	2019-05-22	gcardona
83824633	LL	LL, 26.10%	1	-17	2019-02-28	2019-04-19	2019-04-20	2019-05-01	Reese
83902069	PRP	PRP, 87.20%	15	10	2019-03-04	2019-05-17	2019-05-18	2019-05-28	Kriesel
83961197	LL	LL, 0.50%	18	10	2019-03-07	2019-05-10	2019-05-11	2019-05-28	Will Hockensmith
83964473	LL	LL, 94.00%	1	-27	2019-03-07	2019-04-19	2019-04-20	2019-04-21	gunhed
83994613	LL	LL, 1.00%	23	8	2019-05-11	2019-05-17	2019-05-18	2019-05-26	ATH
83997299	LL	LL, 23.80%	24	7	2019-05-12	2019-05-17	2019-05-18	2019-05-25	Michael Quevillon

[GAPa]

Originally Posted by Madpoo

I'm not sure how or why, but it was assigned as a first-time PRP check.

I manually switched it to a double-check and you should be good. I wonder if that had anything to do with the mismatched set of previous results on it. The bit of code that assigns work as either first or double-check may have run into something funny because of that.

I recently received https://www.mersenne.org/report_expo...0118541&full=1. It seems to me as if it's assigned as a first-time test just like the assignment in your previous discussion. If I recall correctly, it has been the same with my previous PRP double-checks.

[kriesel]

Originally Posted by GAPa

I recently received https://www.mersenne.org/report_expo...0118541&full=1. It seems to me as if it's assigned as a first-time test just like the assignment in your previous discussion. If I recall correctly, it has been the same with my previous PRP double-checks.

In this case, there's an LL and a type 1 PRP. It looks like the server may be not handling well, cases of type 1 PRP needing a double check when there's a nonmatching primality test type on the same exponent. It would be interesting to see if that is the case for your other PRP DC assignments.

[GAPa]

Originally Posted by kriesel

In this case, there's an LL and a type 1 PRP. It looks like the server may be not handling well, cases of type 1 PRP needing a double check when there's a nonmatching primality test type on the same exponent. It would be interesting to see if that is the case for your other PRP DC assignments.

My previous PRP double-checks are https://www.mersenne.org/report_expo...8126487&full=1, https://www.mersenne.org/report_expo...9368761&full=1, https://www.mersenne.org/report_expo...9361587&full=1 and https://www.mersenne.org/report_expo...9099901&full=1. As mentioned, I believe they all looked the same. I don't know if it matters, but I my work preference is first-time PRP tests, but I have set 'DC instead of LL percentage' to 2 per cent (previously 5 per cent, but I lowered it a while ago).

[kriesel]

Originally Posted by GAPa

My previous PRP double-checks are https://www.mersenne.org/report_expo...8126487&full=1, https://www.mersenne.org/report_expo...9368761&full=1, https://www.mersenne.org/report_expo...9361587&full=1 and https://www.mersenne.org/report_expo...9099901&full=1. As mentioned, I believe they all looked the same. I don't know if it matters, but I my work preference is first-time PRP tests, but I have set 'DC instead of LL percentage' to 2 per cent (previously 5 per cent, but I lowered it a while ago).

That third one https://www.mersenne.org/report_expo...9361587&full=1 shows differing PRP residue types.

[petrw1]

Originally Posted by petrw1

1. Less than 20% unfactored below 1M. We're at about 10.1%. 65 to go I calculate. Alex is moving this along though not alone. Should be 2019.

2. Less than 2,000,000 unfactored under 100M. 16,735 to go, about what we did in the last year. 2020 might be possible but optimistic.

And 1 is done. We just passed less than 20% unfactored under 1M