mersenneforum.org

mersenneforum.org (https://www.mersenneforum.org/index.php)
-   Data (https://www.mersenneforum.org/forumdisplay.php?f=21)
-   -   Newer milestone thread (https://www.mersenneforum.org/showthread.php?t=13871)

rudy235 2019-05-10 12:29

[QUOTE=dcheuk;516279]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.[/QUOTE]

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 2019-05-10 14:00

[QUOTE=rudy235;516376]Preferably the user that is beginning the PRP might be wise to abandon his/her assignment and start a LL test if possible.[/QUOTE]

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 2019-05-12 17:37

Three additional exponents have been completed.

[code]
83556937 PRP 2019-04-11 Kriesel
83902069 PRP 2019-03-04 Kriesel
83998979 LL 2019-03-11 Juampa
[/code]
16 to go.

Madpoo 2019-05-13 17:53

[QUOTE=dcheuk;516381]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.[/QUOTE]

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. :smile: 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 2019-05-17 00:49

[QUOTE=Madpoo;516633]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.[/QUOTE]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 2019-05-18 15:09

13 to go.

[CODE]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[/CODE]

GAPa 2019-05-20 02:02

[QUOTE=Madpoo;514830]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.[/QUOTE]I recently received [url]https://www.mersenne.org/report_exponent/?exp_lo=80118541&full=1[/url]. 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 2019-05-20 02:18

[QUOTE=GAPa;517212]I recently received [URL]https://www.mersenne.org/report_exponent/?exp_lo=80118541&full=1[/URL]. 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.[/QUOTE]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 2019-05-20 03:31

[QUOTE=kriesel;517215]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.[/QUOTE]My previous PRP double-checks are [url]https://www.mersenne.org/report_exponent/?exp_lo=78126487&full=1[/url], [url]https://www.mersenne.org/report_exponent/?exp_lo=79368761&full=1[/url], [url]https://www.mersenne.org/report_exponent/?exp_lo=79361587&full=1[/url] and [url]https://www.mersenne.org/report_exponent/?exp_lo=79099901&full=1[/url]. 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 2019-05-20 13:05

[QUOTE=GAPa;517224]My previous PRP double-checks are [URL]https://www.mersenne.org/report_exponent/?exp_lo=78126487&full=1[/URL], [URL]https://www.mersenne.org/report_exponent/?exp_lo=79368761&full=1[/URL], [URL]https://www.mersenne.org/report_exponent/?exp_lo=79361587&full=1[/URL] and [URL]https://www.mersenne.org/report_exponent/?exp_lo=79099901&full=1[/URL]. 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).[/QUOTE]
That third one [url]https://www.mersenne.org/report_exponent/?exp_lo=79361587&full=1[/url] shows differing PRP residue types.

petrw1 2019-05-21 20:22

[QUOTE=petrw1;515446]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.[/QUOTE]

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


All times are UTC. The time now is 22:54.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.