[QUOTE=Prime95;434898]I just tried [URL]http://mersenne.org/manual_gpu_assignment[/URL] and entered:

TF for first-time LL
80000000 to 85000000
Lowest exponents
75 (bit level)

and got an assignment just above 82000000[/QUOTE]

Hmm. Can this be put as a link in the regular mersennse.org menu please?
Also the experimental List of Assignments page that showed the Category of the LL and DC tests and all the other fields?

@LaurV: yes, my Misfit is set to 2^75 -- and every automatic assignment I've ever gotten has been in the nosebleed region as if it were a regular manual CPU request from primenet.

Is it time for 76 bits? It seems the crossover point is between 80M and 90M, depending on the card (80M for a 1080, 84M for my 580's, 90M for my 760, which gets occasional work).

It also appears we'll be finishing the work for everything that isn't category 4 within a couple of weeks.

[QUOTE=Mark Rose;439168]Is it time for 76 bits? It seems the crossover point is between 80M and 90M, depending on the card (80M for a 1080, 84M for my 580's, 90M for my 760, which gets occasional work).

It also appears we'll be finishing the work for everything that isn't category 4 within a couple of weeks.[/QUOTE]

The answer would seem to be - yup.

Is it better at this stage to go straight from 72->76 for the next grouping? Or should we concentrate on lifting a large forward region up one layer at a time once we are ahead of demand?

[QUOTE=airsquirrels;439174]The answer would seem to be - yup.

Is it better at this stage to go straight from 72->76 for the next grouping? Or should we concentrate on lifting a large forward region up one layer at a time once we are ahead of demand?[/QUOTE]

From what I can tell, we're already of the LL'ers, except the 6.1K at 71M (which should be done shortly).

We're still behind the P-1'ers, which are working in the 81M range. If I understand correctly the P-1 rate can be somewhat controlled by how high we take the TF work, since the more TF done, the smoother any factor found by P-1 would have to be, reducing the range to be checked by P-1.

I guess it might make sense to wrap up 79M to 80M at 75 bits first, then start going to 76 bits.

[QUOTE=airsquirrels;439174]The answer would seem to be - yup.[/QUOTE]

Definitely. Really right now we're mostly continuing to feed the P-1'ers. The 71M range should be finished well before the Cat 2 wavefront gets there.

[QUOTE=airsquirrels;439174]Is it better at this stage to go straight from 72->76 for the next grouping? Or should we concentrate on lifting a large forward region up one layer at a time once we are ahead of demand?[/QUOTE]

I think that's largely a function of what people want to do, taking into consideration what type of card they have.

Also, as I said earlier, I plan to pass control of TF'ing back to Primenet once we're comfortably ahead of all the wavefronts (including the P-1'ing), when GPU72 no longer has to hold candidates to prevent them from being assigned sub-optimally TF'ed and P-1'ed.

GPU72 will continue to function (pretty graphs, people competing in the rankings, etc.), but will be more of a proxy to Primenet; much like the transition for the LL'ing / DC'ing. George, Aaron and I will have to do some work to complete this, but it should be mostly transparent to everyone else.

Also, a separate topic is the 332M range. People seemed to have lost interest in TF'ing there, so I released all the candidates back to Primenet to assign as it seemed best. There's still a great deal of TF'ing to be done up there, but it seemed unreasonable for GPU72 to hold candidates when work wasn't being done on them.

As always, feedback welcomed. And also, as always, thanks for all the cycles everyone! :tu:

[QUOTE=Mark Rose;439176]We're still behind the P-1'ers, which are working in the 81M range.[/QUOTE]

We cross-posted...

Actually, if you drill down on the 1882 P-1 assignments in 81M, they are all held by a user who likes to come into Primenet and take thousands of Manual Assignments at a time, and then never completes any of them.

GPU72 pulled its "rip-cord" within a few minutes of observing this, and released candidates appropriately TF'ed so real P-1 workers would get them. The said 1882 assignments should expire mid October for proper processing.

Potential downtime...
 

So, as the recent issue with HTTPS connections has demonstrated, the GPU72 server needs to be upgraded. The poor little thing is ancient! CentOS 5.11!

The underlying hardware is still good (it's a co-located server), but I might take the opportunity to migrate permanently over to an EC2 or GCE instance instead.

I will let everyone know on this thread when changes are taking place, while trying to minimize any disruption. But if anyone sees anything strange, please bring it forward.

Having run EC2 extensively, I suggest using GP2 for storage. It will perform more than well enough, even if not using an EBS optimized instance. If you can tune RAM, a c4.large would be perfect.

[QUOTE=chalsall;439276]...but I might take the opportunity to migrate permanently over to an EC2 or GCE instance instead.[/QUOTE]

So, I was in the process of spinning up an EC2 and a GCE instance to compare their performance vs. pricing compared to my current co-located server in preparation for the GPU72 upgrade.

To my shock, there is no way to set a reverse DNS lookup PTR record for an IP address under GCE, even with a reserved IP!

Further, I've read (but haven't empirically tested to confirm myself) that all outbound port 25 (SMTP) traffic is blocked under GCE. (Based on the amount of spam I receive from EC2 instances, clearly this isn't the case there.)

Hmmm... While reverse lookups won't be needed by most people, this lack of functionality is troubling. There have been trouble tickets open on this with Google since 2013; they seem to be just ignoring it.

I don't believe AWS has reverse PTR customization either. I've never seen it.

Also, if you are going to be sending email, I'd configure your MTA to relay through SES. Most of the EC2 IPs have a bad reputation.