Right, the cloud resources are nearly limitless- # cpu,memory,disk space. LL makes use of fast cores and fast memory, not a lot of memory nor disc space. It's kind of special, and I think George has optimized cost vs performance. The cloud also incurs cooling costs that we all just sort of take for granted with a few computers. So while I can accommodate cooling 20 cores without doing anything special, they can't. GPUs were going great and then they gave up on reasonably cheap double precision performance.

[QUOTE=stars10250;437153]But how does that explain my similar experience with microsoft, google, and compute bricks? None of the services were reasonably priced. I launched LL jobs, and watched how my free bank money depleted. I guess I used on-demand instances because I want to compute. I compute on many cores 24/7, that's what I want out of the cloud for LL. I tried specifying the price I was willing to pay for compute, and my jobs never ran. I kept raising my offer but it got boring with jobs never running. I want compute today, now, and tomorrow, and the day after. I also don't want to have to spend time starting and stopping jobs and then restarting them. I tried another service for naming my price and the cost got to be far beyond the space heater sitting next to me. My experience was universal and poor. For continuous 24/7 compute, none of the services were even kind-of-close to economical. If it's so reasonable, then we should all switch. I should say, if you want/need any number of cores, the cloud scales without issue. It just costs a lot.[/QUOTE]

But for LL testing you don't need "continuous 24/7 compute", so why pay more for something you don't need?

On-demand pricing means you rent by the hour and can stop at any time or continue as long as you want, and your instance is guaranteed never to get interrupted. This is the most expensive kind.

Reserved term pricing means you commit to renting for a year, or three years. You can get large discounts for this, or even larger if you pay the whole amount upfront (roughly a 60% discount in this case). Your instance is guaranteed never to get interrupted.

Spot pricing means your instance can get interrupted at any time if you get outbid. Essentially Amazon sells off their moment-by-moment spare capacity this way, you get terminated if a big paying customer shows up. This is by far the cheapest, and the only kind that makes sense for LL crunching. If you run a website in the cloud, it needs to be available 24/7, it needs to have high bandwidth, low latency, fast networking to connect to some database, and all that good stuff; but, if you just do number crunching you don't need guaranteed uptime or anything else.

At current best available spot prices for a c4.large instance, you can get an 88% discount compared to on-demand prices.

[QUOTE=stars10250;437153]But how does that explain my similar experience with microsoft, google, and compute bricks? None of the services were reasonably priced.[/QUOTE]

In [URL="http://mersenneforum.org/showpost.php?p=402244&postcount=109"]this post from 2015[/URL], you said you'd be willing to pay $18 per LL test (!). At that price I'm pretty sure you could find someone willing to take your money (not me, but talk to xilman).

I'd suggest that what you'd get for your money would be: 1) your choice of exponent (under 100M) 2) the 64-bit hexadecimal residue value, 3) a copy of the full results.txt output, with InterimResidues=n turned on (from undoc.txt), 4) PrimeNet credit for the result, since it would run under your username, 5) sole discovery credit (jointly with Woltman et al.) and exclusive rights to any applicable third-party prize money (jointly with Woltman et al.), if any, in the exceedingly unlikely event that the exponent turned out to be a Mersenne prime discovery.

That was 2x my cost on a 75M exponent. I figured I would be willing to pay 2x for not having a hot office, having free space, not having to maintain computers etc.

[QUOTE=GP2;437161]In [URL="http://mersenneforum.org/showpost.php?p=402244&postcount=109"]this post from 2015[/URL], you said you'd be willing to pay $18 per LL test (!). At that price I'm pretty sure you could find someone willing to take your money (not me, but talk to xilman).[/QUOTE]
Huh? for which expo range? :razz:

[QUOTE=GP2;437154]Another possibiity for cloud computing would be to do stuff that your home server farm can't do, for instance something highly memory intensive.[/QUOTE]

Yes. I sometimes use such EC2 instances for large Sparse Bundle Adjustment jobs. I don't have machines with 100s of GiBs of RAM just sitting around waiting for work, so it's great being able to cheaply rent such machines as I need them.

[QUOTE=GP2;437154]Maybe you could run a big P−1 test with that if it was worth it to you, I don't know.[/QUOTE]

This wouldn't really make much sense. While lots of RAM helps with P-1, above about 8 GiBs or so the returns quickly diminish.

If I may (respectively) observe... It seems to me that GP2 and stars10250 are going around in circles a bit on this, while actually agreeing with each other and with everyone else here.

Cloud Computing has its place (clearly). But not for GIMPS.

[QUOTE=chalsall;437221]If I may (respectively) observe... It seems to me that GP2 and stars10250 are going around in circles a bit on this, while actually agreeing with each other and with everyone else here.

Cloud Computing has its place (clearly). But not for GIMPS.[/QUOTE]

Actually there is very little agreement and much disagreement here. But at this point there isn't much to add that would not be a rehash.

I'm posting this only to mention that EFS (Elastic File System) is [URL="https://aws.amazon.com/blogs/aws/amazon-elastic-file-system-production-ready-in-three-regions/"]now (finally) ready in a limited number of regions[/URL]. I haven't had a chance to look at it yet, but EFS was supposed to allow multiple instances to share the same filesystem, which might simplify the problem of continuing existing work after old spot instances get terminated and new ones are later automatically started.

[QUOTE=GP2;437372]EFS (Elastic File System) is [URL="https://aws.amazon.com/blogs/aws/amazon-elastic-file-system-production-ready-in-three-regions/"]now (finally) ready in a limited number of regions[/URL]. I haven't had a chance to look at it yet, but EFS was supposed to allow multiple instances to share the same filesystem, which might simplify the problem of continuing existing work after old spot instances get terminated and new ones are later automatically started.[/QUOTE]

It should also make it incredibly easy to have multiple instances crunching the same data and overwrite each others' save files. LOL

[QUOTE=TObject;437382]It should also make it incredibly easy to have multiple instances crunching the same data and overwrite each others' save files. LOL[/QUOTE]

Don't be silly. Within the shared filesystem each instance would create its own subdirectory, and the name of the subdirectory would be the instance-id.

But prior to creating its own subdirectory, a newly launched instance would call "aws ec2 describe-instances", to get a list of all running instances in its own region and availability zone; it would then compare that list to the list of all existing subdirectories it finds. If there are any discrepancies, it will be due to orphan subdirectories left behind by terminated spot instances. Instead of creating its own new subdirectory, the newly launched instance simply renames one of the orphaned subdirectories to its own instance-id, and then starts crunching with the existing worktodo.txt and savefiles.

That way you would never have to do manual cleanup.

Seems straightforward. Am I missing something?

[QUOTE=GP2;437386]Don't be silly.[/QUOTE]

You mean I could not do it if I wanted it?

I'm sure you could have things overwrite each others files if you desired.

I read "Don't be silly" in the same way one would respond to a old-time MS-DOS user first encountering UNIX / Linux and saying this idea of two processes running at the same time sounded like a terrible idea since you could get confused about what processes are running. Or CP/M users using MP/M, etc.