Because things were working so well and others were watching the pot I delayed an update until today.

All exponents below [B][COLOR="Blue"]34,661,527[/COLOR][/B] have been tested and double-checked.
All exponents below [B][COLOR="Blue"]57,861,131[/COLOR][/B] have been tested at least once.

Countdown to testing all exponents below M([B][COLOR="Blue"]57885161[/COLOR][/B]) once: [COLOR="Red"][B]1[/B][/COLOR]
Countdown to first time checking all exponents below 58M: [B][COLOR="Red"]1[/COLOR][/B] (Estimated completion : [COLOR="Green"]2015-10-02[/COLOR])
Countdown to first time checking all exponents below 59M: [B][COLOR="Red"]47[/COLOR][/B] (Estimated completion : [COLOR="Green"]2015-11-02[/COLOR])
Countdown to double checking all exponents below 35M: [B][COLOR="Red"]3,421[/COLOR][/B] (2,868 still unassigned)

Countdown to proving M([COLOR="Green"]37156667[/COLOR]) is the [COLOR="green"]45[/COLOR]th Mersenne Prime: 27,643[/QUOTE]

[/QUOTE]?
:razz:

[QUOTE=Uncwilly;411683]Because things were working so well and others were watching the pot I delayed an update until today.

Countdown to first time checking all exponents below 58M: [B][COLOR="Red"]1[/COLOR][/B] (Estimated completion : [COLOR="Green"]2015-10-02[/COLOR])[/QUOTE]

If you were talking about the single remaining test under 58M...

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.

If my run had shown it was prime, I think I would have let George know but waited to see if the original assignee checked in so they could "discover" it (I don't need the prize money), but it was composite anyway.

[QUOTE=Madpoo;411694]If you were talking about the single remaining test under 58M...

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]Perhaps that is a bug in the recycling rules implementation code? It appeared to be a manual check-in because it had a finish date before the most recent check-in. But it somehow got to 70+ days old with no progress without triggering any recycling.

[QUOTE=Madpoo;411694]If you were talking about the single remaining test under 58M...

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.

If my run had shown it was prime, I think I would have let George know but waited to see if the original assignee checked in so they could "discover" it (I don't need the prize money), but it was composite anyway.[/QUOTE]

Oh, and FYI, my own analysis of M57861131 (the single remaining test) has an ETA of Oct. 5, not Oct. 2. That's based on an observed progress rate of 5.1% daily over the past 13 days.

[QUOTE=retina;411695]Perhaps that is a bug in the recycling rules implementation code? It appeared to be a manual check-in because it had a finish date before the most recent check-in. But it somehow got to 70+ days old with no progress without triggering any recycling.[/QUOTE]

Yeah, I think it had something to do with the client's "next check in date" that it sent at it's last communication. For some reason it was set to a time *after* it was due to be finished, which was weird. I guess you could configure a client to only communicate with Primenet once every few months, but it would finish work before then. Weird at any rate.

[QUOTE=Uncwilly;372515]Straight scale, with primes, and rich data.[/QUOTE][QUOTE=Uncwilly;372462]Well, I have fairly good data from ~Oct 2010. Is this good enough for the current period?[/QUOTE]Updates on the 2 graphs noted in the above posts:

Oh, you mean that is the time to find a new prime, arn't you? :wink:

Milestone page update (under the hood)
 

Hey all,

I've been working a little on the milestone page to make it show the stats a little faster.

Let me give some quick behind the scenes... Currently, every time that page is loaded it has to query some stuff from SQL for each of the countdown stats. It's not a huge burden, but it does add up. When we had a false positive the other day for a prime, it got me to thinking about what would happen if a new prime is found, and the site starts getting a bunch of traffic?

The home page, download page, history, etc. would probably get a surge in traffic and those are all pretty much static, but that milestone page would also probably get more views and that would probably be a bad thing.

Solution was to cache the stats instead of a query each time it's viewed. Right now I have it cache for 5 minutes at a time. George had mentioned some other possible things we could do with that, but for now if you want to check it out:
[URL="http://www.mersenne.org/report_milestones/default.mock.php"]http://www.mersenne.org/report_milestones/default.mock.php[/URL]

There's a little footer at the bottom of each page that shows the time it took the server to render the HTML. For the cached version it's a fraction of a second (assuming you got the cached info... you may be the lucky person who views it and triggers a fresh query). We're talking 60-70 milliseconds. The old version is taking me an average 2.4 - 2.5 seconds. Quite a difference.

Any feedback on this? Is 5 minutes fine? The milestones don't typically change that drastically and I only set it to 5 since the <58M milestone is approaching... if we didn't have any pending completions I might set it higher like an hour or two.

Enjoy! Once we've fleshed it out a bit we'll move that new scheme so it replaces the live page. The page itself is the same except for the text that shows the date/time the stats were last fetched, so that's how you'll know when it's live.

[QUOTE=Madpoo;411846]
Any feedback on this? Is 5 minutes fine? The milestones don't typically change that drastically and I only set it to 5 since the <58M milestone is approaching... if we didn't have any pending completions I might set it higher like an hour or two.[/QUOTE]

Once an hour is fine in my opinion

[QUOTE=petrw1;411849]Once an hour is fine in my opinion[/QUOTE]

In my experience with caches for this kind of thing, there's very little difference between five and sixty minutes. If the page is only hit a few times per minute, there's very little system impact even with no caching. So if you can cache for a minute, you're good. When the system gets busy, say 10 hits per second in this case, then the caching pays off by producing a handful of requests per five minutes instead of 3000 requests.

So why a handful of requests? The problem is the [url=https://en.wikipedia.org/wiki/Thundering_herd_problem]thundering herd problem[/url]. When the cache suddenly expires, [i]all[/i] the parallel requests will start rebuilding it. There are mitigation techniques, but if the system can handle the thundering herd until the cache is rebuilt, the mitigations are not always worth implementing. The most important thing is to make sure the cache is written atomically so two parallel generations don't interfere.