[QUOTE=Mark Rose;419668]He probably already knows it's prime :grin:[/QUOTE]

LOL... I wish. :smile:

I could do what chalsall suggested. Before I do it I should probably look again at the recycling rules so I know when it was going to be recycled for sure and then turn in my result a day or two beforehand. With the grandfathered assignments I went through and figured out just when they'd expire based on their progress, and that was *more* complicated, so these should be easier to figure out.

I think for the cat 1 LL tests it was 90 days after assignment which would peg that one as expiring on Jan 2. If they don't magically finish it before then maybe I can check mine in on New Years Eve as a special treat for the milestone. LOL

My case for occasional saving of interim results on the server
 

[url]http://www.mersenne.org/assignments/?exp_lo=66587000&exp_hi=66600000&execm=1&exdchk=1&exp1=1&extf=1[/url]

There are 5 66M LL results here within hours of completing that seem to be abandoned and will have to START ALL OVER...

[QUOTE=petrw1;419871][URL]http://www.mersenne.org/assignments/?exp_lo=66587000&exp_hi=66600000&execm=1&exdchk=1&exp1=1&extf=1[/URL]

There are 5 66M LL results here within hours of completing that seem to be abandoned and will have to START ALL OVER...[/QUOTE]

I understand the frustration, but do you really want to bet your cycles on work of unknown provenance?

[QUOTE=kladner;419873]I understand the frustration, but do you really want to bet your cycles on work of unknown provenance?[/QUOTE]

Patience.

[QUOTE=blip;419661]Yes. That's what I pointed to [URL="http://mersenneforum.org/showthread.php?t=20679"]here[/URL].[/QUOTE]

It's weird because your reported ETA is so much *sooner* than the actual ETA (which I'm estimating as Jan. 11th at 23:31 UTC) :smile:

Usually when my rolling averages are wrong, it's in the other direction, where it's reporting ETAs that are a lot farther out than reality, not sooner.

My guess is maybe your rolling average is really super high but mprime isn't getting as many cycles, and for whatever reason the rolling average isn't updating itself very well, so it still think you ought to be running way faster.

Odd that it's off by so much... mprime is saying 5 more days but in reality it's more like 21. That's not the normal amount of wrongness?

Are you running something very CPU intensive, to the point where the rolling average is already as low as it can go? There's a lower limit on it but if it's running even slower than that you'll have wildly inaccurate *overestimates* like you've been seeing.

In other words, something could be wrong with your configuration, or you simply have something using a lot of CPU nearly continuously?

[QUOTE=kladner;419873]I understand the frustration, but do you really want to bet your cycles on work of unknown provenance?[/QUOTE]

IMHO what might be a reasonable compromise:
- From Unknown/Unreliable/Inconsistent contributors only
(For many of us who NEVER(?) abandon an assignment saving would be a waste)
- Once "close" to complete save the intermediate file. Pick your favorite number: 75%; 80%; 90%.
- If it does complete the save file is simply erased.
- If not let a designate (or the server itself) complete it.
- BUT to address the "...unknown provenance..." mark it as SUSPECT
- If the next test matches it becomes the Double Check. YAY!!!
- If NOT it becomes a first time test BUT hopefully this will be the rare case.

[QUOTE=petrw1;419924]IMHO what might be a reasonable compromise:
- From Unknown/Unreliable/Inconsistent contributors only
(For many of us who NEVER(?) abandon an assignment saving would be a waste)
- Once "close" to complete save the intermediate file. Pick your favorite number: 75%; 80%; 90%.
- If it does complete the save file is simply erased.
- If not let a designate (or the server itself) complete it.
- BUT to address the "...unknown provenance..." mark it as SUSPECT
- If the next test matches it becomes the Double Check. YAY!!!
- If NOT it becomes a first time test BUT hopefully this will be the rare case.[/QUOTE]

I am wondering if interim residues might help save time spent on a corrupted LL. Say you start from a save file. If the next interim failed to match, would that give a hint of the likely outcome?

Sigh... M58970231 checked in
 

I wasn't paying too much attention and when I checked in a batch of results, that final 58M exponent was in there.

Well, I still don't think the original person was going to finish, and I was planning to check it in around Dec 31, but honestly, I'm on vacation for the next couple weeks and I'd rather not worry about holding that back. :smile:

Anyway, it's done... wasn't prime (I *would* have noticed that).

Milestone page updated, and I tossed in extra countdowns up to 67M:
[URL="http://www.mersenne.org/report_milestones/"]http://www.mersenne.org/report_milestones/[/URL]

[QUOTE=kladner;419927]I am wondering if interim residues might help save time spent on a corrupted LL. Say you start from a save file. If the next interim failed to match, would that give a hint of the likely outcome?[/QUOTE]

One problem presented by these ideas is that the interim files aren't small. Sure, individually the file for something in the 72M range is "only" 9.2 MB, but cumulatively, for all of the assignments out there... well, it's a lot of data.

By way of estimate, take the exponent size and divide by 8 to get the approx file size in bytes.

For all active LL and DC assignments, that would add up to:
815,845,182,349 bytes (816 GB / 760 GiB).

Granted, many active assignments have zero progress. If I only include assignments with a percent done > 0:
259,718,199,046 bytes (260 GB / 242 GiB).

Sure, okay, disk storage [I]could[/I] handle that, but what about bandwidth concerns? How often would each assignment be expected to check in their latest interim file? Probably not time based, but every XX %.

Let's say it was every 25%, so realistically it would upload an interim file 3 times (at 25, 50 and 75%). So you'd be uploading 3x whatever. It would be spread out over however many days... I haven't the foggiest idea what the average time is for a worker to reach 25% complete. :smile: Depends on exponent size and CPU speed, so any average will be wildly misleading. LOL

Anyway, you get the idea... storage and bandwidth are the problems with any kind of interim file repository. Back in dialup days it was even more so than today, but even now with nice fast internet connections, on the server side at least, there's a cost to bandwidth. I forget how much monthly data the server's current home allows (it's higher than what we use, I'll leave it at that), but suffice to say, it's less than it would need to be.

On other server colocations, you're not paying for total data per month, but rather it's billed at a 95th percentile of bandwidth, so it's a little more possible on a budget but only if the uploads (and occasional downloads?) are spread out evenly to avoid big spikes at peak times of day or something. I have a feeling the Prime95 client, were it to automate uploading interims at whatever %, it would average fairly smoothly over the course of a day between all clients.

[QUOTE=Madpoo;419937]One problem presented by these ideas is that the interim files aren't small...[/QUOTE]

An alternate method could involve saving the 64-bit residues along the way. Right now the server only saves the final residue. If it were to save residues every 10% along the way, a double-checker who comes along later would be able to compare results every 10% rather than once at the end.

Question then is, what should happen when a mismatch occurs at some step along the way? Maybe it's immediately made available for a simultaneous triple-check since we know early on that a mismatched final residue is coming.

That wouldn't really speed anything up necessarily, but then again, we'd have residues at the different percentages from people who didn't bother completing the whole thing.

Imagine some newbie starts a double-check and only gets up to 10% but it mismatches the first time check at that some point in time.

It might not be a "sure thing", but for my "strategic double-checking" where we try to find the bad apples ahead of the DC wavefront, that would be a good clue to check those out first. The newbie that gave up might have been bad, but it could be an indicator the first test was bad even though no full DC was done.

Another potential idea is that Prime95 could be fitted up with a newfangled "quit GIMPS" option. Let's say the newbie tries it out and then says "meh, don't need this". Some big "QUIT GIMPS" button would upload their current interim file at whatever iteration which the new assignee could get.

It depends on user participation and not just "stop and delete the program", but you get the idea...

[QUOTE=Madpoo;419901]It's weird because your reported ETA is so much *sooner* than the actual ETA (which I'm estimating as Jan. 11th at 23:31 UTC) :smile:...[/QUOTE]

Well, that system is a bit short on memory, which also could be faster. So, as soon as I can afford it, I will add more and faster RAM. It sports an i7-4930K and runs mprime with 5 exponents plus [URL="http://www.mersenne.org/report_exponent/?exp_lo=450000017&full=1"]this one[/URL]. So, it will be busy for some time.

But anyways, it moves forward all right. I just wanted to give a heads up here and manage expectations.