[QUOTE=rudy235;411890]
Was this the case of a first LL test that gave composite and no one doing a second LL? Seems a bit odd that 5 years passed (1985-1988) without that exponent being checked again. :ermm:[/QUOTE]
In pre-GIMPS era the search was not so systematical and not so coordinated. People "guessed" where primes could lay using whatever method and started testing few exponents around that value. GIMPS stepped in later, in fact it founds the last 13 primes, only. Even during its era, in the beginning the search was not very systematical. There is no known case where a first test was wrong, and a second test found a prime. Unless Madpoo finds a prime for one of the expos I doublechecked, and he stubbornly triple check them, haha, in that case I will be the first idiot in history who missed a prime two times :w00t:

[QUOTE=LaurV;411893]In pre-GIMPS era the search was not so systematical and not so coordinated. People "guessed" where primes could lay using whatever method and started testing few exponents around that value. GIMPS stepped in later, in fact it founds the last 13 primes, only. Even during its era, in the beginning the search was not very systematical. There is no known case where a first test was wrong, and a second test found a prime. Unless Madpoo finds a prime for one of the expos I doublechecked, and he stubbornly triple check them, haha, in that case I will be the first idiot in history who missed a prime two times :w00t:[/QUOTE]

So.. can we safely say that this will be the first time all the exponents smaller than the current Mersenne Prime Record are verified once and found to be composite?

I can imagine M(31) was the last time something like this has happened before in the late 18th Century. Yes, I realize that it was trial division and not LL tests what was used then to discover M(31)

[QUOTE=rudy235;411890]
When was the last time that all mersenne exponents up to the largest mersenne prime –in this particular case M(48)– have been checked once and found composite?[/QUOTE]

From the milestones page:

November 14, 2001 Prime M(13466917) is discovered!
2001-09-25 All exponents below 8,000,000 tested at least once.

[QUOTE=rudy235;411890]When was the last time that all mersenne exponents up to the largest mersenne prime –in this particular case M(48)– have been checked once and found composite?[/QUOTE]

It has happened 3 times before:
2012-09-05 to 2013-01-25 (142 days)
2001-07-25 to 2001-11-14 (112 days)
1998-09-26 to 1999-06-01 (248 days)
Total: 502 days (out of 6898 days since GIMPS first prime)

[CODE]
[COLOR="Red"]2013-01-25 Prime M(57885161) discovered!! 14 discovered 13 tested
2012-09-05 All exponents below M(43112609) tested at least once. 13 discovered 13 tested
[/COLOR]2012-09-05 All exponents below M(42643801) tested at least once. 13 discovered 12 tested
2010-12-25 All exponents below M(37156667) tested at least once. 13 discovered 11 tested
2010-12-25 All exponents below M(32582657) tested at least once. 13 discovered 10 tested
2010-07-29 All exponents below M(30402457) tested at least once. 13 discovered 9 tested
2009-04-12 Prime M(42643801) discovered!! 13 discovered 8 tested
2009-04-08 All exponents below M(25964951) tested at least once. 12 discovered 8 tested
2009-02-23 All exponents below M(24036583) tested at least once. 12 discovered 7 tested
2008-09-06 Prime M(37156667) discovered!! 12 discovered 6 tested
2008-08-23 Prime M(43112609) discovered!! 11 discovered 6 tested
2008-07-04 All exponents below M(20996011) tested at least once. 10 discovered 6 tested
2006-09-04 Prime M(32582657) discovered!! 10 discovered 5 tested
2005-12-15 Prime M(30402457) discovered!! 9 discovered 5 tested
2005-02-18 Prime M(25964951) discovered!! 8 discovered 5 tested
2004-10-03 All exponents below M(13466917) tested at least once. 7 discovered 5 tested
2004-05-15 Prime M(24036583) discovered!! 7 discovered 4 tested
2003-11-17 Prime M(20996011) discovered!! 6 discovered 4 tested
[COLOR="YellowGreen"]2001-11-14 Prime M(13466917) discovered!! 5 discovered 4 tested
2001-07-25 All exponents below M(6972593) tested at least once. 4 discovered 4 tested[/COLOR]
[COLOR="Cyan"]1999-06-01 Prime M(6972593) discovered!! 4 discovered 3 tested
1998-09-26 All exponents below M(3021377) tested at least once. 3 discovered 3 tested[/COLOR]
1998-09-19 All exponents below M(2976221) tested at least once. 3 discovered 2 tested
1998-01-27 Prime M(3021377) discovered!! 3 discovered 1 tested
1997-10-11 All exponents below M(1398269) tested at least once. 2 discovered 1 tested
1997-08-28 All exponents below M(1257787) tested at least once.
1997-08-24 Prime M(2976221) discovered!! 2 discovered 0 tested
1997-03-28 All exponents below M(859433) tested at least once.
1997-01-15 All exponents below M(756839) tested at least once.
1996-11-13 Prime M(1398269) discovered!! 1 discovered 0 tested[/CODE]

Thanks!:smile:

[QUOTE=ATH;411899]It has happened 3 times before:
2012-09-05 to 2013-01-25 (142 days)
2001-07-25 to 2001-11-14 (112 days)
1998-09-26 to 1999-06-01 (248 days)
Total: 502 days (out of 6898 days since GIMPS first prime)

[CODE]
[COLOR="Red"]2013-01-25 Prime M(57885161) discovered!! 14 discovered 13 tested
2012-09-05 All exponents below M(43112609) tested at least once. 13 discovered 13 tested
[/COLOR]2012-09-05 All exponents below M(42643801) tested at least once. 13 discovered 12 tested
2010-12-25 All exponents below M(37156667) tested at least once. 13 discovered 11 tested
2010-12-25 All exponents below M(32582657) tested at least once. 13 discovered 10 tested
2010-07-29 All exponents below M(30402457) tested at least once. 13 discovered 9 tested
2009-04-12 Prime M(42643801) discovered!! 13 discovered 8 tested
2009-04-08 All exponents below M(25964951) tested at least once. 12 discovered 8 tested
2009-02-23 All exponents below M(24036583) tested at least once. 12 discovered 7 tested
2008-09-06 Prime M(37156667) discovered!! 12 discovered 6 tested
2008-08-23 Prime M(43112609) discovered!! 11 discovered 6 tested
2008-07-04 All exponents below M(20996011) tested at least once. 10 discovered 6 tested
2006-09-04 Prime M(32582657) discovered!! 10 discovered 5 tested
2005-12-15 Prime M(30402457) discovered!! 9 discovered 5 tested
2005-02-18 Prime M(25964951) discovered!! 8 discovered 5 tested
2004-10-03 All exponents below M(13466917) tested at least once. 7 discovered 5 tested
2004-05-15 Prime M(24036583) discovered!! 7 discovered 4 tested
2003-11-17 Prime M(20996011) discovered!! 6 discovered 4 tested
[COLOR="YellowGreen"]2001-11-14 Prime M(13466917) discovered!! 5 discovered 4 tested
2001-07-25 All exponents below M(6972593) tested at least once. 4 discovered 4 tested[/COLOR]
[COLOR="Cyan"]1999-06-01 Prime M(6972593) discovered!! 4 discovered 3 tested
1998-09-26 All exponents below M(3021377) tested at least once. 3 discovered 3 tested[/COLOR]
1998-09-19 All exponents below M(2976221) tested at least once. 3 discovered 2 tested
1998-01-27 Prime M(3021377) discovered!! 3 discovered 1 tested
1997-10-11 All exponents below M(1398269) tested at least once. 2 discovered 1 tested
1997-08-28 All exponents below M(1257787) tested at least once.
1997-08-24 Prime M(2976221) discovered!! 2 discovered 0 tested
1997-03-28 All exponents below M(859433) tested at least once.
1997-01-15 All exponents below M(756839) tested at least once.
1996-11-13 Prime M(1398269) discovered!! 1 discovered 0 tested[/CODE][/QUOTE]

[QUOTE=rudy235;411897]So.. can we safely say that this will be the first time all the exponents smaller than the current Mersenne Prime Record are verified once and found to be composite?[/QUOTE]

There is a real possibility a prime can be found during double check. It is not a big chance but much higher than I originally thought.

If you check this thread: [url]http://www.mersenneforum.org/showthread.php?t=20372[/url] Madpoo is finding lots of computers giving mostly bad results and most of the results are proved wrong when people are double/triple/quad checking them.

[QUOTE=LaurV;411893]Unless Madpoo finds a prime for one of the expos I doublechecked, and he stubbornly triple check them, haha, in that case I will be the first idiot in history who missed a prime two times :w00t:[/QUOTE]

I don't know why you insist on double-checking your own work. LOL As far as I can tell, your machines have been working well, so you're worrying over nothing. :smile:

[QUOTE=ATH;411906]There is a real possibility a prime can be found during double check. It is not a big chance but much higher than I originally thought.

If you check this thread: [url]http://www.mersenneforum.org/showthread.php?t=20372[/url] Madpoo is finding lots of computers giving mostly bad results and most of the results are proved wrong when people are double/triple/quad checking them.[/QUOTE]

Yeah, so far my overall success* rate has been about 33%. I had a string of even better results (60%+) the other day which was fun. I think others have had even better success* since I've been trying to leave the easier pickings for other people.

* = success meaning I got a different (correct?) residue than the first check

[QUOTE=ATH;411906]There is a real possibility a prime can be found during double check. It is not a big chance but much higher than I originally thought.

If you check this thread: [url]http://www.mersenneforum.org/showthread.php?t=20372[/url] Madpoo is finding lots of computers giving mostly bad results and most of the results are proved wrong when people are double/triple/quad checking them.[/QUOTE]

Thank you.
Is the possibility of not finding a prime after 2 LL tests, comparable to that of not finding a prime in the first LL test (within a range lets say exponent 60,000,000 to 80,000,000)

In other words how sure are we after doing the first LL run that there are no primes in the range? 98%? 99%? 99.9%? 99.999?

I hope the question makes any sense.:smile:

[QUOTE=rudy235;411937]Thank you.
Is the possibility of not finding a prime after 2 LL tests, comparable to that of not finding a prime in the first LL test (within a range lets say exponent 60,000,000 to 80,000,000)

In other words how sure are we after doing the first LL run that there are no primes in the range? 98%? 99%? 99.9%? 99.999?

I hope the question makes any sense.:smile:[/QUOTE]

Basically what you'd want to know is: What is the average error rate for first time checks?

The answer is a little murky, and that's because we don't know the error rate until we've swept through and done the double-checking.

We can say for sure that the error rate for exponents below 34,661,527 (everything below that has been DC'd) is:
61,047 bad out of a total 746,062 exponents tested at least twice (at least 1,492,124 tests) = ~4.1 % error rate

In truth, those 746,062 exponents have 1,574,499 tests done... some were done more than twice, including the triple checks by yours truly and others, or people just doing quality control tests.

But if we break it down into smaller chunks, not just the grand total from 2 up to the latest DC, but let's say maybe 30M up to 34.6M:
7886 bad out of 196855 good tests = 4.0 %... slightly lower.

Similarly between 20e6 and 30e6: 17,307 bad out of 438,199 good tests = 3.95% failures.

Now, if we look at the relatively small # of exponents above 40M that have been DC'd so far, we get:
Bad = 599, Good tests (total) = 21,290 for an error rate of "only" 2.8%. But as you might guess, that's misleading because there are still so many untested first time checks out there, we don't really know the total error rate. Based in historical averages, it's probably still going to be around 4%, we just won't know until many years from now.

Anyway, the #'s do change over time as we push hardware to new levels of exertion (larger FFTs using more memory, or maybe when GPUs got into the LL game). But it still seems to hover in the 3.9%-4.1% range no matter which range of exponents I look at.

And honestly, it would be beyond what I feel like doing to analyze whether the bad check in those cases was the first one or if it was done later... in many cases for those smaller exponents we don't have the exact date it was checked in anyway, so it would be hard to tell. If I had to guess, and based on my work with doing needed triple-checks of exponents in the 34M range (I've done a few hundred now), it seems like it's half and half. In about half of the cases, the first test was bad, and the other half the double-check that was done by someone was bad and my triple-check proved the first one was correct.

That's anecdotal and based on my spotty memory of what I saw when looking at results for a few seconds each. But if I'm even close, that means maybe 2% were done wrong the first time.

Which makes it even more impressive that I've been able to crunch some stats on machines and do strategic double-checking with (for me) a 30-40% rate of finding those bad machines. And hopefully the others who have been helping out have had even better rates of success with that, over 50% if I'm crunching the numbers right... :smile:

I even did some queries to look at exponents that have been double-checked with a mismatch, and where *both* systems are in the "suspect" category. But honestly, I only found a few of them and the query is so "expensive" (lots of CPU) that I dare not run it too often. LOL But it has given me a few where my triple-check matched neither, so I've mentioned the exponent if anyone wanted to do the quad check. :smile:

[QUOTE=Madpoo;411942]
Similarly between 20e6 and 30e6: 17,307 bad out of 438,199 good tests = 3.95% failures.

Now, if we look at the relatively small # of exponents above 40M that have been DC'd so far, we get:
Bad = 599, Good tests (total) = 21,290 for an error rate of "only" 2.8%. [/QUOTE]
Very nice statistics, thanks. Note that this comes in line with what George said in the very beginning in the math page of GIMPS server, that the historical error rate is around 3%. Right now, you support that very well, with numbers.

Ignoring exponents with duplicate tests (a third confirmation or multiple bad tests), what's the ratio of exponents with any nonzero number of bad tests to total exponents?

[QUOTE] Countdown to testing all exponents below M(57885161) once: 0
Countdown to first time checking all exponents below 58M: 0 ()[/QUOTE]
:party:

[B]2015-10-04 All exponents below M(57885161) tested at least once. 14 discovered 14 tested[/B]
2013-01-25 Prime M(57885161) discovered!! 14 discovered 13 tested
2012-09-05 All exponents below M(43112609) tested at least once. 13 discovered 13 tested
2012-09-05 All exponents below M(42643801) tested at least once. 13 discovered 12 tested
2010-12-25 All exponents below M(37156667) tested at least once. 13 discovered 11 tested
2010-12-25 All exponents below M(32582657) tested at least once. 13 discovered 10 tested

[QUOTE=Madpoo;411694]I poached one of them. It hadn't reported in for about a month, hadn't started yet at the time. It seemed abandoned by user "Xebecer"? Well, that assignment is now a DC.[/QUOTE]

Not anymore. Someone apparently with a valid assignment ID from 6 months ago has completed the double-check. [url=http://www.mersenne.org/report_exponent/?exp_lo=57398083&exp_hi=&full=1]M57398083[/url]

[QUOTE=cuBerBruce;411960]Countdown to testing all exponents below M(57885161) once: 0
Countdown to first time checking all exponents below 58M: 0 ()[/QUOTE]

And I just updated the milestone page with the latest dates.

While I was at it, I swapped over to the cached version of the milestone info and added in the 60M and 61M countdowns so we have more to obsess over. :smile:

[QUOTE=cuBerBruce;411971]Not anymore. Someone apparently with a valid assignment ID from 6 months ago has completed the double-check. [url=http://www.mersenne.org/report_exponent/?exp_lo=57398083&exp_hi=&full=1]M57398083[/url][/QUOTE]

That's definitely weird. Oh well... at least Xebecer still doesn't seem to have checked anything in, which I assumed would be the case, but what odd timing that someone with an expired assignment on that *finally* after months and months checks something in at long last, shortly after I did. Weird.

[QUOTE=Madpoo;411988]And I just updated the milestone page with the latest dates.[/QUOTE]This line still appears in the report:[code]• Countdown to testing all exponents below M(57885161) once:
[/code]

[QUOTE=retina;412059]This line still appears in the report:[code]• Countdown to testing all exponents below M(57885161) once:
[/code][/QUOTE]

Oh... whoops. :smile:

I mean, no, it's not there, what are you talking about?

[QUOTE=Madpoo;412061]I mean, no, it's not there, what are you talking about?[/QUOTE]You are right. It must have been in my imagination only. Sorry to bother you with my mental problems. Please carry on with whatever you were doing.

[QUOTE=GIMPS milestones]Countdown to first time checking all exponents below 61M: [URL="http://www.mersenne.org/assignments/?exp_lo=58496057&exp_hi=61000000&execm=1&exp1=1&extf=1&exdchk=1"]1,560[/URL] [COLOR=black]([B][COLOR=Red]666[/COLOR] [/B]still unassigned)[/COLOR][/QUOTE]
Yarrr, there must be a prime laying there... :devil:

[QUOTE=retina;412062]You are right. It must have been in my imagination only. Sorry to bother you with my mental problems. Please carry on with whatever you were doing.[/QUOTE]

(That's because I quickly removed the evidence before I hit "submit reply") :devil:

[QUOTE=Madpoo;412066](That's because I quickly removed the evidence before I hit "submit reply") :devil:[/QUOTE]

Whoosh!

[QUOTE=Madpoo;411942]Basically what you'd want to know is: What is the average error rate for first time checks?
...
We can say for sure that the error rate for exponents below 34,661,527 (everything below that has been DC'd) is:
61,047 bad out of a total 746,062 exponents tested at least twice (at least 1,492,124 tests) = ~4.1 % error rate
[/QUOTE]

For what it's worth, I was looking into something else (how well the error code tracks with the eventual error rate).

In short, I found out that if you check in a result and Primenet marks it as "Suspect", there's a HIGH probability it's bad. If the known good/bad where it was originally marked suspect:
31185 bad, 27486 good (and 6450 still marked suspect, pending a triple-check).

Counting the known bad/good, we arrive at an error rate of 31185/(31185+27486) = 53.2%. Ouch.

Conversely, the known error rate for "00000000" (again, only counting the "known bad / known good", ignoring the numerous unknowns) is just 1.8%.

1.8% isn't bad... better than the average 4.1% I mentioned. So if you report an error free run, you're actually doing far better than if you had any other kind of error.

Oddly, if you ever get the error code "01000100" you have an even LOWER chance of it being bad... only 0.8%. Must be because that indicates the program encountered some repeatable error (I think that's what it means?) and the fact that it could be repeated means the system is actually more stable than if it went undetected in the first place?

For all of the "non-suspect" error codes, it breaks down thusly so far:
29008 bad, 1467321 good, for a known error rate of 1.9%

In summary, don't let the 4% error rate scare you too much... if you report a non-suspect result, the odds are better than that, and you should only sweat it if you get a suspect result at which point it's a wee bit worse than a flip of the coin.

That is useful information in those last couple of posts about error rates, could a mod maybe split those into a new thread under the FAQ/information subforum?

[QUOTE=Madpoo;411989]That's definitely weird. Oh well... at least Xebecer still doesn't seem to have checked anything in, which I assumed would be the case, but what odd timing that someone with an expired assignment on that *finally* after months and months checks something in at long last, shortly after I did. Weird.[/QUOTE]

Well, with about 2 days to go before Xebecer's assignment would have been recycled (if there hadn't been any poaching), the exponent [url=http://www.mersenne.org/report_exponent/?exp_lo=57398083&exp_hi=&full=1]M57398083[/url] has now been triple-checked. But the triple check was not done by Xebecer or anyone else who had ever been assigned the exponent (as far as I can tell). If Xebecer is actually working on it, and checks in a result, that will make a quadruple-check.

[QUOTE=Madpoo;412393]...
In summary, don't let the 4% error rate scare you too much... if you report a non-suspect result, the odds are better than that, and you should only sweat it if you get a suspect result at which point it's a wee bit worse than a flip of the coin.[/QUOTE]

I had a thought just now... if we assume a roughly 4% error rate, considering the 422,811 exponents left before we verify M48, that means there are potentially another 16-17K bad exponents hiding in there, waiting for someone to do a *proper* check on it. :smile:

But that's not really all of the story... a lot of those "probably bad" have already been DC'd without a match. There are something like 5000 exponents below 58M that are awaiting a triple-check. Many of those were marked suspect the first time around so they got reassigned pretty quick and resulted in the mismatch.

That still leaves quite a bit of uncharted territory out there. Right now the trick for me is trying to find these bad machines, but at some point we'll have to get more creative to try and find the bad stuff in advance. Otherwise, the DC work will hopefully, eventually get done in that range. Until the very last one is done I'll probably still have my theory that there's a hidden, missing prime in there. I reckon there are still 10-11K possibilities for that.

The latest dark background is terrible.
[url]http://www.mersenne.org/report_milestones/[/url]
:yucky: hard to read the black text further down. Hard to read the green text near the top. :yucky:

[QUOTE=retina;412988]The latest dark background is terrible.
[url]http://www.mersenne.org/report_milestones/[/url]
:yucky: hard to read the black text further down. Hard to read the green text near the top. :yucky:[/QUOTE]

I don't think you see what the rest of us see:[ATTACH]13264[/ATTACH] or it has been fixed in the last hour or so...

[QUOTE=sdbardwick;412991]I don't think you see what the rest of us see:[ATTACH]13264[/ATTACH] or it has been fixed in the last hour or so...[/QUOTE]Fixed now. So whatever happened has now unhappened.

[QUOTE=retina;412997]Fixed now. So whatever happened has now unhappened.[/QUOTE]

Must have been gremlins in the system... I didn't change anything, honest. I'm glad it's back to normal for you now.

[QUOTE=Madpoo;413039]Must have been gremlins in the system... I didn't change anything, honest. I'm glad it's back to normal for you now.[/QUOTE]The entire page had one background that was light grey at the edges and progressed to darker grey towards the centre. I refreshed a couple of times but it remained like that. Anyhow after sdbardwick posted, I checked it again and then it was fine again.

You have a saint in your evil lair! He is sabotaging you!

[QUOTE=LaurV;413060]You have a saint in your evil lair! He is sabotaging you![/QUOTE]There is more than one saboteur in here, I am sure. But I was using my VPN so unless they precomputed the parameters to break the DH exchange then I doubt they can MITM me. Anyhow, I've been using the 2048 bit prime for DH exchanges forever, so such computing ability doesn't yet exist (barring some incredible theory advances) to crack the DH exchange.

[QUOTE=retina;413061]There is more than one saboteur in here, I am sure. But I was using my VPN so unless they precomputed the parameters to break the DH exchange then I doubt they can MITM me. Anyhow, I've been using the 2048 bit prime for DH exchanges forever, so such computing ability doesn't yet exist (barring some incredible theory advances) to crack the DH exchange.[/QUOTE]

:goodposting:

[QUOTE=retina;413061]There is more than one saboteur in here, I am sure. But I was using my VPN so unless they precomputed the parameters to break the DH exchange then I doubt they can MITM me. Anyhow, I've been using the 2048 bit prime for DH exchanges forever, so such computing ability doesn't yet exist (barring some incredible theory advances) to crack the DH exchange.[/QUOTE]

Yeah, but did you pick a unique prime? Lots of VPN software work off a fixed list; those have been compromised already. [url]https://weakdh.org/[/url]

[QUOTE=Mark Rose;413097]Yeah, but did you pick a unique prime? Lots of VPN software work off a fixed list; those have been compromised already. [url]https://weakdh.org/[/url][/QUOTE]Barring an unknown theoretical advance the computation requirements for 2048 bit primes are quite considerable. By comparison the 1024 bit primes are a cake walk.

[QUOTE=retina;413121]Barring an unknown theoretical advance the computation requirements for 2048 bit primes are quite considerable. By comparison the 1024 bit primes are a cake walk.[/QUOTE]

You do, of course, conduct yourself such that you assume that all communications are known?

[QUOTE=chalsall;413123]You do, of course, conduct yourself such that you assume that all communications are known?[/QUOTE]Sometimes we just gotta roll along and not get too paranoid. 2048 bit DH and some 256 bit AES across a private VPN, yeah I think I'm okay until at least tomorrow. More likely Mini-me will be the one to dob me in, the little bugger.

[QUOTE=retina;413126]Sometimes we just gotta roll along and not get too paranoid. 2048 bit DH and some 256 bit AES across a private VPN, yeah I think I'm okay until at least tomorrow. More likely Mini-me will be the one to dob me in, the little bugger.[/QUOTE]

Psssts... The n'th digit of pi.

Don't tell anyone....

Or rot13 applied 2 times, like someone said here... (or rot78? hehe)

:direction:

Remember when dannytoearth had 4 of the last 10 sub-56M first LL assignments? Well, Danny just recently finished those four assignments - 2 as DCs and 2 as TCs.

[url=http://www.mersenne.org/report_exponent/?exp_lo=55027163&exp_hi=&full=1]M55027163[/url]
[url=http://www.mersenne.org/report_exponent/?exp_lo=55059383&exp_hi=&full=1]M55059383[/url]
[url=http://www.mersenne.org/report_exponent/?exp_lo=55079077&exp_hi=&full=1]M55079077[/url]
[url=http://www.mersenne.org/report_exponent/?exp_lo=55107499&exp_hi=&full=1]M55107499[/url]

:banana:

[QUOTE=cuBerBruce;413207]Remember when dannytoearth had 4 of the last 10 sub-56M first LL assignments? Well, Danny just recently finished those four assignments - 2 as DCs and 2 as TCs.

[url=http://www.mersenne.org/report_exponent/?exp_lo=55027163&exp_hi=&full=1]M55027163[/url]
[url=http://www.mersenne.org/report_exponent/?exp_lo=55059383&exp_hi=&full=1]M55059383[/url]
[url=http://www.mersenne.org/report_exponent/?exp_lo=55079077&exp_hi=&full=1]M55079077[/url]
[url=http://www.mersenne.org/report_exponent/?exp_lo=55107499&exp_hi=&full=1]M55107499[/url]

[/QUOTE]

LOL... that's kind of funny... 3 months later, I think that's around what I'd guessed, but I don't remember now. I should look up my previous estimates for the two of them I was keeping an eye on.

Ah... here's the last estimate I said about those two back on July 7:
[QUOTE]M55027163 and M55079077 are increasingly unlikely to finish before expiring.

The progress on those has slowed greatly and right now it looks like they may finish up in 2 more months (63 and 66 days), but they'll expire before then (at the current rate, maybe in 35-45 days).[/QUOTE]

I guess that means I'd estimated them finishing around Sep 15... only off by a month. :smile:

[QUOTE]Countdown to first time checking all exponents below 59M: 6 (Estimated completion : 2015-11-15)[/QUOTE]

Someone finished an LL test for M58944947 about 3 weeks after being recycled for exceeding the 90-day limit on cat 1 assignments. (I guess the LL test finished in 2013 had been considered suspect, since this exponent was still being considered a first LL. Since the new result matched, Scott Hemphill's assignment has been expired.)

It seems to be that there are a fair number of people "promising" to do assignments quickly, but don't finish their assignments on time. Perhaps part of the reason for this is that the Account Assignment Details page neither indicates what category each LL/DC assignment is, nor gives the anticipated expiration/recycling date. Thus it is rather non-obvious to users how much time their assignments have left.

[size=5][b]5[/b][/size]

[QUOTE]Countdown to first time checking all exponents below 59M: 5 (Estimated completion : 2015-11-17)[/QUOTE]

The same user has completed another expired assignment (took 112 days - should have been done in 90 days). s_c's assignment is now a double-check.

Edit: Of the 5 remaining, 2 have recently expired assignments by this same user. Beware, GlennMaitz and DRH, your assignments may become DCs.

Not a sub-59M exponent, but another case of a "top ten" LL being finished by someone after their assignment expired. The Captain finished his 90-day assignment for [url=http://www.mersenne.org/report_exponent/?exp_lo=59098009&full=1]M59098009[/url] in 98.3 days.

4

[QUOTE=cuBerBruce;414474]It seems to be that there are a fair number of people "promising" to do assignments quickly, but don't finish their assignments on time.[/quote]

Is this just because it's not very clearly documented how you tell GIMPS "I'm stopping after these exponents are done"?

(PS: how _do_ you tell GIMPS "I'm stopping after these exponents are done"?)

Pretty much exact a year ago, the new rules for recycling and reassignment went into effect. A chaotic system was replaced by a more gradual system that favours reliable clients and assigns them higher priority exponents. In the past year the recycling of assignments dating from the old system resulted in a vast amount of work for the clients that work on the highest priority exponents, among them the lowest ones without any LL done.

Only now has the dust settled down from the change and has the time started that the work distribution between different category clients becomes stable. Looking at the [URL="http://www.mersenne.org/primenet/"]primenet distribution page[/URL], in the column[FONT="Courier New"] Unproven - No LL [/FONT]there is no bulk any more at the trailing edge, currently about 60M to 66M.

As a result the lowest exponent listed on the milestones page will start to go up faster and more gradual than in the past year.

[QUOTE=fivemack;414925](PS: how _do_ you tell GIMPS "I'm stopping after these exponents are done"?)[/QUOTE]
Stop mprime
Put "NoMoreWork=1" in prime.txt
Restart mprime

Or from the menus, "Advanced", "Quit Gimps", and select "finish the work before quitting". The effect is exactly the same, the "NoMoreWork=1" is added to the config file. You can substitute to "=0" and restart P95 if you change your mind. If the work is finished and you already "quit", and you want back at the kings' table, :razz: you have to use "Test" menu, and check the box "use Gimps to get work", which was automatically deselected when you "quit".

[QUOTE=blip;414928]Stop mprime
Put "NoMoreWork=1" in prime.txt
Restart mprime[/QUOTE]

MaxExponents=0
also works in prime.txt :)

IMHO that "Quit Gimps" label needs to be reworded.

I was always afraid of clicking on that, because I do not want to 'Quit Gimps' when I am simply retiring a computer.

[QUOTE=ATH;414933]MaxExponents=0
also works in prime.txt :)[/QUOTE]
But this may unreserve the work which is not started yet.

Edit: agree about wording of "quit gimps", not very fortunate wording, it was confusing for me too, years ago, in the beginning. However, nothing wrong happens if you click it, like deleting your user from PrimeNet or other "nightmares". It is just what explained before, the "NoMoreWork=1" line is added to the config file, so no more work will be requested from the server, and you will be asked if you need to quit immediately or finish the queued work. If you choose to quit immediately, the the flag for "don't use gimps" is also set. Otherwise, the work is finished, the flag is set after. You can resume anytime, by "Test"/"PrimeNet"/"Use Gimps to get work". That's it.

[QUOTE=LaurV;414995]But this may unreserve the work which is not started yet.[/QUOTE]

No, it finishes everything left in the worktodo.txt, I have used it before.

Good to know! Thanks ATH!
I used to lower this number in the past (like from 50 to 30 for example) and work got unreserved. I use to set it very high when I add manual work (especially P-1, which are lots of them).
Edit: Currently I have:
MaxExponents=300
UnreserveDays=365
to avoid unreserving work which I add by hand. I don't know how they combine together, just founded by trial and error that "this holds".

[QUOTE=cuBerBruce;414648]The same user has completed another expired assignment (took 112 days - should have been done in 90 days). s_c's assignment is now a double-check.

Edit: Of the 5 remaining, 2 have recently expired assignments by this same user. Beware, GlennMaitz and DRH, your assignments may become DCs.[/QUOTE]

That user has finished another one of these recycled assignments. DRH now has a DC.

[size=5][b]3[/b][/size]
[QUOTE]Countdown to first time checking all exponents below 59M: 3 (Estimated completion : 2015-11-20)[/QUOTE]

[B]2[/B]

we are speeding up ...

Yet another top ten exponent has been completed by someone with an expired assignment. M59142739 was completed in 102.8 days, nearly two weeks late. Scott Hemphill is once again the victim, but at least this time he keeps his assignment as a DC.

[QUOTE=cuBerBruce;416083]Yet another top ten exponent has been completed by someone with an expired assignment. M59142739 was completed in 102.8 days, nearly two weeks late. Scott Hemphill is once again the victim, but at least this time he keeps his assignment as a DC.[/QUOTE]

I don't know if this is already some automatic process, but people who have checked the box to get preferred assignments but then let their stuff expire probably need to have that flag disabled.

EDIT: In this case it wouldn't have mattered... that user might have had assignments expire but then they keep working on it and check it in. There aren't any that were totally abandoned.

On the other hand, there are 121 users who have chosen to get preferred assignments but have over 5 expirations in their history... some with quite a large amount (when looking at just LL/DC work, one user has 91 expired assignments but still wants to get preferred work).

But assignments can expire for different reasons... a DC/LL could be poached, it could be factored, or it could have just taken too long. I'd have to dig into the "why" to really tell if a user is trying to get preferred stuff and then wandering off on a regular basis. :smile:

[SIZE="7"][U][B][COLOR="Red"]2 [/COLOR][COLOR="Orange"] Y[/COLOR][COLOR="Yellow"]E[/COLOR][COLOR="SeaGreen"]A[/COLOR][COLOR="Blue"]R[/COLOR][COLOR="Indigo"]S [/COLOR][COLOR="DarkOrchid"] ! [/COLOR][COLOR="Magenta"] ! [/COLOR][COLOR="Cyan"] ! [/COLOR][/B][/U][/SIZE]:party:

Based upon recent trends, we now have less than 2 years until we 'complete' the 79.3 million range.
November 6, 2017 is the current projected completion date. We are however trending downward on that date, so we may actually complete things before then.

[QUOTE=Uncwilly;416122]Based upon recent trends, we now have less than 2 years until we 'complete' the 79.3 million range.
November 6, 2017 is the current projected completion date. We are however trending downward on that date, so we may actually complete things before then.[/QUOTE]

Excuse my ignorance, but what is special about 79.3M?

[QUOTE=Mark Rose;416129]Excuse my ignorance, but what is special about 79.3M?[/QUOTE]

Back in the day (early 2000's) it was the largest exponent that P95 could work on, I spent several years (not a misprint) testing 79919219 starting on a Celeron-300...

[QUOTE=Mark Rose;416129]Excuse my ignorance, but what is special about 79.3M?[/QUOTE]
[QUOTE=Gordon;416135]Back in the day (early 2000's) it was the largest exponent that P95 could work on,[/QUOTE]
And almost since the start has been featured a table like the one here:
[url]http://www.mersenne.org/report_classic/[/url]

[QUOTE=Gordon;416135]Back in the day (early 2000's) it was the largest exponent that P95 could work on, I spent several years (not a misprint) testing 79919219 starting on a Celeron-300...[/QUOTE]

OK, I'll bite. If 79.3M was the largest exponent that could be tested, why and how were you testing 79919219? You say "not a misprint", which rules out a typo (or does it?).

[QUOTE=VBCurtis;416157]OK, I'll bite. If 79.3M was the largest exponent that could be tested, why and how were you testing 79919219? You say "not a misprint", which rules out a typo (or does it?).[/QUOTE]
And 79919219 has a small factor, even by the year 2000 standards: 245247148314673 (15 digits)

He probably meant: [URL="http://mersenne.org/M79299719"]http://mersenne.org/M79299719[/URL]

[QUOTE=ATH;416190]He probably meant: [URL="http://mersenne.org/M79299719"]http://mersenne.org/M79299719[/URL][/QUOTE]

If so, it's even sadder that so much time was spent on it only to get a bad result. Well... it happens...

[QUOTE=ATH;416190]He probably meant: [URL="http://mersenne.org/M79299719"]http://mersenne.org/M79299719[/URL][/QUOTE]

[QUOTE=Madpoo;416211]If so, it's even sadder that so much time was spent on it only to get a bad result. Well... it happens...[/QUOTE]

I'm more interested that our illustrious friend 'For Research' also turned in a bad result. (Presumably he has already noticed and fixed whatever the problem may have been)

[QUOTE=Dubslow;416212]I'm more interested that our illustrious friend 'For Research' also turned in a bad result. (Presumably he has already noticed and fixed whatever the problem may have been)[/QUOTE]

Good question... made me look it up.

Turns out that one result is his only bad one from that CPU, not just in 2015 but going back to 2013 (and 875 good results, with only 13 unknowns remaining).

[QUOTE=Madpoo;416215]Good question... made me look it up.

Turns out that one result is his only bad one from that CPU, not just in 2015 but going back to 2013 (and 875 good results, with only 13 unknowns remaining).[/QUOTE]

:huh:

[QUOTE=Madpoo;416215]Turns out that one result is his only bad one from that CPU, not just in 2015 but going back to 2013 (and 875 good results, with only 13 unknowns remaining).[/QUOTE]

Hmmm... Interesting...

And that was on one of my "Highly Reliable" machines (ECC memory, RAID6, no over-clocking, etc). This is now the second time (that I know of) that this has happened (on two different but identical boxes).

I don't know how this happened. I normally never do LLs; possibly I moved an assignment I got by mistake from a slower machine to a faster one. But that's just a guess.

[QUOTE=chalsall;416258]Hmmm... Interesting...

And that was on one of my "Highly Reliable" machines (ECC memory, RAID6, no over-clocking, etc). This is now the second time (that I know of) that this has happened (on two different but identical boxes).

I don't know how this happened. I normally never do LLs; possibly I moved an assignment I got by mistake from a slower machine to a faster one. But that's just a guess.[/QUOTE]

Just blame solar radiation. :smile:

Seriously though, I wonder if it has anything to do with the size of the exponent and the FFT it uses, or something weird like that. Your result didn't have an error code but the other bad result did (a repeatable one though, so it wasn't marked suspect).

You're right though that ECC and a stable, non-OC'd system should be expected to run flawlessly, so I guess I'm back to solar radiation, or gremlins, or whatever. :)

[QUOTE=blip;415121][B]2[/B]

we are speeding up ...[/QUOTE]

Umm... hmm... we're actually slowing down, but unless you looked at the milestone page daily and made a note of the ETA, you wouldn't notice.

Reason being, this guy: [URL="http://www.mersenne.org/M58702333"]M58702333[/URL]

The person assigned that test has been VERY slow with the progress. Since it was assigned on Sep 19, it's done this:
2015-09-25 - 2.9%
2015-09-26 - 8.9%
2015-09-27 - 10.5%
2015-10-03 - 10.6%
2015-10-04 - 11.8%

And since Oct 4, it's been stuck at 11.8%. It checks in daily, but hasn't moved the progress at all, it just bumps out it's own ETA by another day each time.

At this point it has a rolling daily average progress of only 0.178% per day and wouldn't finish until March 2017. Of course, it went in fits and bursts at first and then nothing for over a month, so who knows...

The other <59M exponent (M58970231) has been doing okay. Average is 1.7485% per day and I calculate a real ETA of Dec 5 (different than it's own estimate of Nov 28 by just one week). But it also goes in fits and bursts... it's at 61.3% now and it's been at that same % for a week... zero progress in one week. Hmmm... But still reports in daily. Go figure.

Hopefully they pick up the pace otherwise I just know someone's going to poach them. I'm not sure about the expiration rule for something like this where they continue to check in daily with zero progress... I don't remember what the assignment age limit is, but if it's 90 days, we could be waiting a while longer. Dec 18 for the first one, Jan 2 for the other.

So, if the folks running those read the forum, this is for you: Pick up the pace. :smile: Don't let these expire before you finish (or someone poaches).

[QUOTE=Madpoo;416272]Just blame solar radiation. :smile:

Seriously though, I wonder if it has anything to do with the size of the exponent and the FFT it uses, or something weird like that. Your result didn't have an error code but the other bad result did (a repeatable one though, so it wasn't marked suspect).

You're right though that ECC and a stable, non-OC'd system should be expected to run flawlessly, so I guess I'm back to solar radiation, or gremlins, or whatever. :)[/QUOTE]

ECC only protects against a single bit flip. Bits can also be flipped outside of main memory, too.

[QUOTE=Mark Rose;416277]ECC only protects against a single bit flip.[/QUOTE]

Not entirely true.

Some ECC implementations can recover from a single bit flip, and can detect two bits flipping in a "word". The latter produces an exception (which often results in a halt).

[QUOTE=Mark Rose;416277]Bits can also be flipped outside of main memory, too.[/QUOTE]

Absolutely.

In the early days of "copy protection" magnetic media (read: floppy discs) were encoded with an "off-on" (fon) bit or sector. Half the time they would read one, the other half they would read zero. Very quickly, of course, the "breakers" would simply comment out the test code.

[QUOTE=chalsall;416279]Not entirely true.

Some ECC implementations can recover from a single bit flip, and can detect two bits flipping in a "word". The latter produces an exception (which often results in a halt).
[/QUOTE]

The HP servers I use are like that. Single bit detect/correct, and two-bit detect (throw error).

As you mentioned, the usual thing that happens is when a 2-bit error is detected, the system will halt/blue-screen/whatever. Correctable single-bit errors get logged and you'll be nagged that something's wrong.

I think there are some caveats to the way it works, like the errors would need to be on the same module or maybe even the same physical chip... I don't recall the details.

Either way, it's rare to have 2 bits fail and you [I]don't[/I] have some kind of indication like a BSOD. It could happen though.

Vaguely related: [URL="http://rick.vanrein.org/linux/badram/index.html"]A neat trick for bad memory[/URL]

1 ...

[QUOTE=blip;417993]1 ...[/QUOTE]

Another case of someone finishing a cat 1 assignment late, after being recycled to someone else. The user finished the assignment in 165 days, so it was 75 days past the 90-day limit.

[QUOTE=blip;417993]1 ...[/QUOTE]

This is the one that came in:
[URL="http://www.mersenne.org/M58702333"]http://www.mersenne.org/M58702333[/URL]

My first thought was "joe-dal" got impatient, poached it. (I don't think "Spin" was going to finish anyway, to be honest).

Turns out, "joe-dal" had an assignment for that going way back to June 20, it expired, but it kept plugging away anyway. It happens.

I guess I should be surprised that "Spin" was assigned a priority exponent at the time (September) and then didn't work on it like they should have. That user does have the preferred assignment bit checked. This could be one of those cases to show why we should uncheck that when they're not living up to the promise they made to work on them.

It may also be that Cat-1 is not strict enough with past performance, queues, and the like.

Does the latest addition to the milestones page show some DB corruption?
[code]# Countdown to first time checking all exponents below 62M: 275 (1 still unassigned)
# Countdown to first time checking all exponents below 63M: 509 (3 still unassigned)[/code]Checking the [url=http://www.mersenne.org/primenet/]hourly report[/url] does not show any exponents in those ranges as available.

[size=1]I am aware of the different schedules that these pages are updated. But this has persisted for more than a few hours now and the milestones page always shows that number exponents waiting to be assigned.[/size]

I note that the highest sub-60M exponent remaining for first LL testing got recycled. With the new assignee of [url=http://www.mersenne.org/M59969537]M59969537[/url] having an ETA of 46 days, I think it's unlikely that the new assignee will beat the old assignee to completing the test. The old assignee was at least 92.7% done with the test.

[QUOTE=retina;418082]Does the latest addition to the milestones page show some DB corruption?
[code]# Countdown to first time checking all exponents below 62M: 275 (1 still unassigned)
# Countdown to first time checking all exponents below 63M: 509 (3 still unassigned)[/code]Checking the [url=http://www.mersenne.org/primenet/]hourly report[/url] does not show any exponents in those ranges as available.

[size=1]I am aware of the different schedules that these pages are updated. But this has persisted for more than a few hours now and the milestones page always shows that number exponents waiting to be assigned.[/size][/QUOTE]

Just spitballing here, but maybe they're checked out for something besides LL at the moment (TF, P-1, ECM).

I can check in detail later on when I have time.

[QUOTE=Madpoo;418084]Just spitballing here, but maybe they're checked out for something besides LL at the moment (TF, P-1, ECM).[/QUOTE]The hourly report would show that in the "Assigned" column but those are all blank except for the LL section.

[QUOTE=cuBerBruce;418083]I note that the highest sub-60M exponent remaining for first LL testing got recycled. With the new assignee of [url=http://www.mersenne.org/M59969537]M59969537[/url] having an ETA of 46 days, I think it's unlikely that the new assignee will beat the old assignee to completing the test. The old assignee was at least 92.7% done with the test.[/QUOTE]

I checked my "assignment history" stats and I'm projecting that original assignment will finish in 4.7 more days.

I don't know... he had 3 months and almost made it, but again, I'm pretty sure when it was assigned it was a priority assignment and that user did have the "preferred assignment" option checked.

I wonder if we could look at users who have that option checked and see how many assignments they've let expire... maybe turn that option off. After all, sometimes users might check that with the best of intentions and then life happens... unchecking that box probably isn't high on their list of priorities if they even remember it's there at all.

Well, not a huge problem, probably, but that is the second time in one day that we've seen this come up.

[QUOTE=Madpoo;418084]I can check in detail later on when I have time.[/QUOTE]

Looked into it. Weird... these 3 exponents were set to be available for *double* checking even though no first time check has been done yet:
61535039
62121131
62327819

I think I just need to change the "availability type" on those to be first-time instead of double checks and they should get assigned out pretty quick.

Reasons for that happening? Could be someone had checked in a suspicious looking LL test that George invalidated, but that "make available for DC" never got set back. That was my first thought, but it could have been something else entirely... no idea.

This sounds familiar, like the same thing happened recently with something in the 57M or 58M range... I should probably just check and see if there are any other exponents in that situation.

[QUOTE=Madpoo;418133]... I should probably just check and see if there are any other exponents in that situation.[/QUOTE]

Checked, found 4 more between 63M and 100M.

63316289
63316753
63344161
65035609

I'll move those to first-time checks as well since I don't see any reason why they'd be available for double-checks when no first-time check has been done yet.

EDIT: Searched above 100M as well and didn't see any others. That should take care of it.

[QUOTE=Madpoo;418169]That should take care of it.[/QUOTE]Except that the underlying problem appears to have not been discovered, so it could happen again in the future?

[QUOTE=retina;418171]Except that the underlying problem appears to have not been discovered, so it could happen again in the future?[/QUOTE]

Yes. I have no idea why this would happen. There is a stored procedure that determines how to add rows to the available assignments table. I don't see how that procedure could list an exponent for DC when there are no LL tests completed.

[QUOTE=Prime95;418172]Yes. I have no idea why this would happen. There is a stored procedure that determines how to add rows to the available assignments table. I don't see how that procedure could list an exponent for DC when there are no LL tests completed.[/QUOTE]Has it happened in the past and no one spotted it? Are there "DC"ed exponents with only one LL test completed?

[QUOTE=retina;418173]Has it happened in the past and no one spotted it? Are there "DC"ed exponents with only one LL test completed?[/QUOTE]

That's done independently (determining when an exponent has been DC'd) and it's pretty thorough, taking into account that it needs matching residues from different shift counts (or for the old code before shift counts, they had to come from different software).

What George referred to is a process that will take exponents that perhaps were expired assignments and makes them available again. When it makes them available it looks at the available data and sets the proper first time or DC work type along with some other useful stats like how far it's been factored and thus it's "difficulty" level (which also varies based on if it's a first time or DC work type).

To "reset" them I actually ran the stored procedure to make them available again, and it did it correctly, setting them to first time work and setting the difficulty appropriately. So I'd lean more towards something funky happened with the first time check, and by then they'd already been made available as a DC.

Now that we know there aren't any more like that, if it happens again we'll know that it was something that got muddled between now and then so we'll have something to go on. With those other ones, it would be hard or impossible to say when they got put into that weird state. I might peek back at any logs available since we moved to the new server in case anything shows up, but I won't hold my breath. :smile:

EDIT: Searched the web server logs, didn't see any activity on those exponents in the past year so whatever happened predated the new server setup at least.

[QUOTE=Madpoo;418086]I checked my "assignment history" stats and I'm projecting that original assignment will finish in 4.7 more days.[/QUOTE]

That user has now finished it, so the new assignee now has exponent 59969537 as a double-check. It came in sooner than Madpoo's prediction.

[url=http://www.mersenne.org/report_exponent/?exp_lo=46842001&full=1]M46842001[/url] could use a triple check :)

DoubleCheck=46842001,72,1

[QUOTE=Mark Rose;418217][url=http://www.mersenne.org/report_exponent/?exp_lo=46842001&full=1]M46842001[/url] could use a triple check :)[/QUOTE]

Mine. Will be about a week.

[QUOTE=chalsall;418239]Mine. Will be about a week.[/QUOTE]

Totally posted that in the wrong thread. It's been a crazy week.