[QUOTE=chalsall;388074]As the "poacher", please let me defend myself...

2. From a more temporally spread view of the same report (which I have access to because of my spiders), it was clear that these three candidates would take /much/ more time to actually complete than allowed under the current (implemented) Primenet recycling rules.
[/QUOTE]

I believe Chris is threading carefully, but I just couldn't help thinking about this joke:
[URL="https://m.youtube.com/watch?v=FIrYci5TZiU"]Ronald Reagan on the Soviet Union[/URL]

[QUOTE=tha;388153]... but I just couldn't help thinking about this joke:
[URL="https://m.youtube.com/watch?v=FIrYci5TZiU"]Ronald Reagan on the Soviet Union[/URL][/QUOTE]

That was a joke?

[QUOTE=chalsall;388196]That was a joke?[/QUOTE]

Let us hope so, else he shot his friend for real. In these days of Putin we may recycle these jokes, but he doesn't seem like the guy with the best sense of humor though.

A soonish milestone:

[code]Countdown to testing all exponents below M(57885161) once:[I] 5,624[/I][/code]Is it likely a new MP will be found before this one is "one-time" proved?

[QUOTE=davar55;388236]Is it likely a new MP will be found before this one is "one-time" proved?[/QUOTE]
I would say that the answer is yes.
Based upon our past history, we are past the average time to discover the next MP. The average is 455 days between, we are now at 666 days since the last. If you take our average gap and add the average deviation from that (not the standard dev.), it is less than 3 months.

It will be interesting to see what George's change to the assignment rules have on the progress of the wavefront.

[QUOTE=davar55;388236]A soonish milestone:

[code]Countdown to testing all exponents below M(57885161) once:[I] 5,624[/I][/code]Is it likely a new MP will be found before this one is "one-time" proved?[/QUOTE]

There's even some chance the next one found will be smaller than that one. :)

Double-checking is still years away from proving M48 and not all the smaller exponents have even been first-time checked.

What's more, of the ones that *have* been first-time checked, I just looked and 82 of those results were marked "suspect" due to some error codes during the LL check.

21 of those 82 'suspect' results are assigned to someone else currently, but that's another 61 exponents where the first check was suspect, and *probably* bad (they're all in the 56M-57M range).

So, hey... who knows. :smile: Maybe the dry spell is because wherever that little gem is, it's still hiding because it got passed over during some bad run, and it's waiting for double/triple checking.

I think George might have it setup to hand out exponents again as a "new" first time check if the original run was suspect... I don't know how else to explain the 21 of those that are already re-assigned. Which makes sense... I'd hate to wait around for double-checking to realize that one of those was actually prime, which could be years.

[QUOTE=davar55;388236]Is it likely a new MP will be found before this one is "one-time" proved?[/QUOTE]

I would say probably not. Davieddy was good at bringing us monthly updates on the expected time to next prime. Back then, the estimate was consistently in the 4 years area. That means at our current rate we expect to find one prime over the next four years. Could be more primes, but could be less.

Note that the fact that we haven't found one in the last year and a half is irrelevant. We expect 1 in the next four years. If we don't find a prime before 2018, we will still expect one prime the following 4 years (2019-2022).

All the above assumes, computer power and number of users keeps up with the demands (and lower probabilities) of larger exponents.

Is there any way to immediately send out work that has been returned with an error code?

[QUOTE=Xyzzy;388252]Is there any way to immediately send out work that has been returned with an error code?[/QUOTE]

The server already does do that as far as I understand it.

I have three cores working on CAT 1 double checks. Quite some of the assignments are for triple checks even though the error codes are 0.

[QUOTE=Xyzzy;388252]Is there any way to immediately send out work that has been returned with an error code?[/QUOTE]

My gut tells me it handles that, by basically ignoring a result if the error code isn't zero, for purposes of assignments. If the next check-in happens to match residues, then it's a verified LL test, no harm no foul. More often than not, that one with errors ends up being the loser in a triple-check though.

The reason my gut tells me that is because exponents seem to be reassigned for LL or DC work well ahead of when it would if that original "suspect" result was counted as just a regular result.

Also, a couple weeks back I saw a handful of old false positives... just to be sure I re-ran them all. George will do some manual interventions with suspicious seeming results (especially false positives), so we can rest assured, he's on the case.

Just in case, I found 3 more of those false positives earlier today when looking at some #'s so I'm re-running those just to cross the t's and dot the i's. They're older ones too and I'm sure George already checked into them but I didn't see any verification results. Call it a mini case of OCD on my part that says "you know, let's just run those again, in case". :smile:

[QUOTE]Countdown to double-checking all 2^P-1 smaller than 10M digits: 49[/QUOTE]

Under 50 to go!