[QUOTE=Madpoo;423838]I don't know exactly what you'd want graphed... Like a graph showing a downward trending line representing the countdown to when everything < 35M will be done? I think it'd be boring. LOL It's probably the kind of data that could easily be charted after the fact... just a count of how many remaining DCs there are for any given point in time below some threshold... but again I fear it'd be a boring mostly straight line ending at zero on some date.[/QUOTE]

Any and all numbers on that page, vs time. Each category could be its own graph, each entry in the category being a particular line on the graph.

I agree that for now it wouldn't be very interesting, but for example if you had the data for the last year, it would be a very nice looking graph. If we want to have data for the next year, we need to start saving it now, hence my request.

Is [URL]http://www.mersenne.org/report_exponent/?exp_lo=601248421&full=1[/URL] this the largest LL test completed to date?

[QUOTE=alpha1;423864]Is [URL]http://www.mersenne.org/report_exponent/?exp_lo=601248421&full=1[/URL] this the largest LL test completed to date?[/QUOTE]

I just completed again factorizaton up to 2^65 :smile:

Madpoo will surely be happy to DC this self verified result again :D

[QUOTE=manfred4;423889]Madpoo will surely be happy to DC this self verified result again :D[/QUOTE]

That was my first thought, too lol

[QUOTE=manfred4;423889]Madpoo will surely be happy to DC this self verified result again :D[/QUOTE]

Ugh, I just got done bellyaching about that one:
[URL="http://www.mersenneforum.org/showpost.php?p=423928&postcount=32"]http://www.mersenneforum.org/showpost.php?p=423928&postcount=32[/URL]

In short, I couldn't if I wanted to, and it seems kind of fishy anyway.

[QUOTE=Dubslow;423855]I agree that the first idea here is quite overkill, but how about Category 0 with 5-10 day return time instead of 60? Or maybe 15 day return time, since on my box, the most efficient use results in around 10-11 day tests at the current Cat 1 DC wavefront.[/QUOTE]

Okay, the more I think about this, the more I like this idea.

I think there should be a fifth category, called Cat 0 for backwards compatibility, with the following entry and completion criteria (differences from Cat 1 bolded):

[code]
First [B]50[/B] assignments

Exponents below [B]35171537[/B]

Assigned to users that promise to complete assignments quickly. Computer must be proven reliable,
returned at least [B]4[/B] results in the last 90 days for each LL worker thread, and
"days of work to queue" <= [B]2[/B]

Must be completed in [B]30[/B] days

Assignments are recycled when assignment is more than [B]30[/B] days old.
[/code]
The 30 day period to completion is quite generous, to help minimize duplicate work that happens in Cat 1 and would happen here too, but I think the 4 results in the last 90 days would still sufficiently guarantee a speedy return well within 15 days, even if there are 30 before the assignment is recycled.

Here's the Cat 1 values for reference:
[code]
First 3000 assignments

Exponents below 35663484

Assigned to users that promise to complete assignments quickly. Computer must be proven reliable,
returned at least 2 results in the last 90 days for each LL worker thread, and
"days of work to queue" <= 10

Must be completed in 60 days

Assignments are recycled when assignment is more than 60 days old.
[/code]

Why does the server even allow LL and DC on the same exponent to be done by the same user? It seems odd to allow that.

[QUOTE=blahpy;423961]Why does the server even allow LL and DC on the same exponent to be done by the same user? It seems odd to allow that.[/QUOTE]

I'm pretty sure that the server won't assign the same exponent to someone twice, but nothing is stopping someone from manually adding an entry to a worktodo.txt file.

That's how I'm trying to verify an overclock on a Skylake i5 right now; doing some unneeded triple checks on some of my own exponents . It made it through three plus days of torture test, but hasn't given me a matching residue yet. Turn down the clock, turn up the voltage, watch the core temps, re-run the tests, repeat. I haven't submitted any yet, but I plan to when they all match. The first time checks were all done by someone else, so why shouldn't I be able to get credit for the triple checks I've run; once they match that is.

[QUOTE=endless mike;423972]I'm pretty sure that the server won't assign the same exponent to someone twice, but nothing is stopping someone from manually adding an entry to a worktodo.txt file.[/QUOTE]

True. It won't automatically assign the same exponent if you did the first time check. But yeah, nothing's stopping people from running it manually and turning it in. Or even by mistake.

Many of Curtis' current self-verified work comes from what I'd assume are worktodo entries that got copied to more than one machine by mistake... first one finishes and then another one turns it in a few days or even months later. It includes the assignment ID but the assignment is no longer there so it just comes in as "unassigned".

Can't exactly reject it in a case like that. 99% of the time I trust the person who turned it in, but then there are the ones I don't know and/or have no reason to trust. :smile:

[QUOTE]That's how I'm trying to verify an overclock on a Skylake i5 right now; doing some unneeded triple checks on some of my own exponents . It made it through three plus days of torture test, but hasn't given me a matching residue yet. Turn down the clock, turn up the voltage, watch the core temps, re-run the tests, repeat. I haven't submitted any yet, but I plan to when they all match. The first time checks were all done by someone else, so why shouldn't I be able to get credit for the triple checks I've run; once they match that is.[/QUOTE]

That's how I'd personally prefer to see people testing their overclocked systems... doing double-checks.

5% of the time you'll get a mismatch anyway because that's the odds that the *other* system got it wrong, but in general you should match, and you're helping get the DC work caught up. :smile:

[QUOTE=Madpoo;424006]Can't exactly reject it in a case like that. 99% of the time I trust the person who turned it in, but then there are the ones I don't know and/or have no reason to trust. :smile:
[/QUOTE]
You can if the shift is the same. Like when not only the worktodo was copied over to other machines, but also some checkpoint file, in that case they will come with the same shift and it can be rejected. But I assume those cases are pretty rare.

[QUOTE=LaurV;424061]You can if the shift is the same. Like when not only the worktodo was copied over to other machines, but also some checkpoint file, in that case they will come with the same shift and it can be rejected. But I assume those cases are pretty rare.[/QUOTE]

Very rare. The server already flags those and it won't mark the DC as complete if that happens.

Well, it seems like it used to be more common, but I've been slowly picking those off with my own checks when they become available. There are a grand total of 5 left, unfortunately all are assigned to someone else. I'm just waiting to poach them if they fall behind. :smile:

[QUOTE=Madpoo;423838]...
I have been working on a fun little set of data today. Took me a while to get some of the data cobbled together.

The count of how many first time versus double-check results were checked in each day... it's a really... interesting... query to figure that out. I have to join on the same LL results for a particular exponent and then see if it had any previous results turned in or not. Took a while to figure out how to make that fast enough that I could go back to January 1, 2010 which I chose as my starting point.
...
I have it mostly ready to go, just need to schedule it as a daily job and then figure out what to do with this data.[/QUOTE]

So I worked on this some more this evening after my real job... I think I have a pretty good set of data, and I set up a job to run daily (especially to gather stats on how many assignments were made the previous day).

Check this page out... it's chock full of Google charts. The data is all pre-generated on the server so it should spit out the page pretty quick, and the rest of the render time is just how long Google's charting plugin takes to draw it all.

The graph for the LL and DC assignments will be mostly accurate for the past couple days when I was grabbing it at midnight, but older data will be missing assignments... when an assignment returns the result, the assignment is deleted, so I don't have historical data for assignments that were made and then finished. As time goes on it'll stabilize, but that's why I only show the past 2 weeks... beyond that and it's just not accurate enough to matter.

Enjoy!
[URL="http://www.mersenne.org/primenet/graphs.php"]http://www.mersenne.org/primenet/graphs.php[/URL]

(as usual, that URL and it's content is subject to change since it's just a beta/work-in-progress)

[QUOTE=Madpoo;424074]Enjoy!
[URL="http://www.mersenne.org/primenet/graphs.php"]http://www.mersenne.org/primenet/graphs.php[/URL][/QUOTE]Blank page. No graphs. Just white space below a standard header.

[size=1][color=grey]JS <blah blah blah> :sad:[/color][/size]

Wow! That is fantastic! :w00t:
Why does the TF graph have such a distinctive pattern? :confused2:

I like these new graphs!

[QUOTE=kladner;424076]Wow! That is fantastic! :w00t:
Why does the TF graph have such a distinctive pattern? :confused2:[/QUOTE]
MTWTFssMTWTFssMTWTFssMTWTFssMTWTFss ?

[QUOTE=retina;424075]Blank page. No graphs. Just white space below a standard header.

[SIZE=1][COLOR=grey]JS <blah blah blah> :sad:[/COLOR][/SIZE][/QUOTE]
There is a graph below the attached, of new accounts, but they only fit 2 to a snip, and I can only post 2 pictures at a time. ;<)

[QUOTE=kladner;424080]There is a graph below the attached, of new accounts, but they only fit 2 to a snip, and I can only post 2 pictures at a time. ;<)[/QUOTE]Thanks.

But the TF cannot be correct. The blue line crosses to the negative (which I assume is each week). Are factors somehow sucked out of the DB?

[QUOTE=retina;424082]Thanks.

But the TF cannot be correct. The blue line crosses to the negative (which I assume is each week). Are factors somehow sucked out of the DB?[/QUOTE]
I don't know, but this is a [U]very first[/U] effort. I imagine that Aaron will do some tuning.
[QUOTE](as usual, that URL and it's content is subject to change since it's just a beta/work-in-progress) [/QUOTE]

[QUOTE]But the TF cannot be correct[/QUOTE]
TF does not match
[url]www.mersenne.ca/status/tf/0/1/1/0[/url]

[QUOTE]Countdown to first time checking all exponents below 62M: [color=red]10[/color] [color=green](Estimated completion : 2016-02-17)[/color][/QUOTE]

The sub-62M milestone is down to 10. This appears to be because of another poach. I find the "Most Recent Cleared" entry a bit peculiar, though:

[CODE]proxy2222
Manual testing
61233727
C
2016-01-26 09:57
19.5
154.7853
2E7B70BBB89ABC__
[/CODE]

Usually when someone poaches, the "Days" field reads 0.0, but in this case it reads 19.5. I am curious why it doesn't read 0.0, since this exponent had been assigned to MikeB (and still is, now as a double-check). Also, the residue does look rather suspicious...

[QUOTE=retina;424082]Thanks.

But the TF cannot be correct. The blue line crosses to the negative (which I assume is each week). Are factors somehow sucked out of the DB?[/QUOTE]

They don't really... I fussed with that stupid thing and I try forcing the baseline to zero, but Google insists on making the baseline a negative number. It probably has to do with the fact that I use dual y-axes on that one since the TF factors and the P-1 + ECM factors have such different daily totals... even when I set the baseline of each to zero it still wasn't working right.

But the data itself is clear (you can look at the page source)... there aren't any "negative" factor counts for any day... an occasional zero perhaps for the P-1+ECM but maybe not even that. The apparent dip below zero is just a visual thing from the scaling, I guess.

The strangely cyclic nature is indeed a Mon-Fri thing with Sat/Sun being low periods. I have no idea why, but it might have to do with that large anonymous GPU72 account? I didn't dive into it more to see where those were coming from or if it's even one user.

The mini spike in P-1+ECM factors is from a day when TJAOI (or however that's spelled) turned in a bunch of ECM factors on small (6 digit) exponents.

[QUOTE=srow7;424092]TF does not match
[url]www.mersenne.ca/status/tf/0/1/1/0[/url][/QUOTE]

Beats me.

I just queried the raw data for Jan 24 and I come up with:[LIST][*]1128 factors by TF (12 of them were two factors for the same exponent, so really only 1116 distinct exponents)[*]33 factors by P-1[*]9 factors by ECM (although 4 of those were for F12... Fermat factoring sometimes skews the results, but whatever... the server accepts that kind of work).[/LIST]
Here's the data as sent to Google Charts for that day:
Date(2016,0,24),1128,42

I can only account for what's on Primenet... not sure what the mersenne.ca discrepancy is but if they're saying 1224 factors for that day and not the 1170 that Primenet is aware of, I don't know how to account for that. I think both systems use UTC, but there's a lag between when mersenne.ca crawls Primenet to get the data... not sure if the timestamps are retained through that, but if they were slightly off, it could account for it... some factors came in a day before or later. It would average out over time if so.

And I don't know if mersenne.ca gets factors from any source besides Primenet?

[QUOTE=Madpoo;424143]The strangely cyclic nature is indeed a Mon-Fri thing with Sat/Sun being low periods. I have no idea why, but it might have to do with that large anonymous GPU72 account? I didn't dive into it more to see where those were coming from or if it's even one user.[/QUOTE]

Nope. GPU72's cyclic workers tend to submit their results over the weekend. Besides, since we're working just before the "wavefronts" to optimal TF depth we rarely find more than 40 factors a day; I imagine that this is someone(s) doing high range TF'ing to low bit levels during the week.

BTW, the new graphs are beautiful!!! :smile:

[QUOTE=cuBerBruce;424128]The sub-62M milestone is down to 10. This appears to be because of another poach. I find the "Most Recent Cleared" entry a bit peculiar, though:
...
Usually when someone poaches, the "Days" field reads 0.0, but in this case it reads 19.5. I am curious why it doesn't read 0.0, since this exponent had been assigned to MikeB (and still is, now as a double-check). Also, the residue does look rather suspicious...[/QUOTE]

The result that came in had an apparently valid assignment ID and it was assigned to them on 2016-01-06.

There is now an assignment for it that's older and is now a double-check. Kind of weird because it doesn't look like it was actually expired (it's expiration date is missing in the DB), but it does seem like it was old enough (assigned 2015-10-30) that it got reassigned...

Kind of weird that it got reassigned to someone on Jan 6 though. That's way too soon for a 90-day expiration on LL cat 1.

Basically I can't explain that one either.

[QUOTE=retina;424082]The blue line crosses to the negative (which I assume is each week). Are factors somehow sucked out of the DB?[/QUOTE]

It's just a visual annoyance linked to using "smoothed" lines (as opposed to "straight" ones) with hundreds of data points and major variations in data. I've seen it happen in XL, LibreOffice... and now in Google Graphs as well ;-)

In any case, kudos to Aaron: the new charts are awesome.

[QUOTE=chalsall;424145]Nope. GPU72's cyclic workers tend to submit their results over the weekend. Besides, since we're working just before the "wavefronts" to optimal TF depth we rarely find more than 40 factors a day; I imagine that this is someone(s) doing high range TF'ing to low bit levels during the week.

BTW, the new graphs are beautiful!!! :smile:[/QUOTE]

Oh, it's user TJAOI. Apparently they're inactive on the weekend, but on M-F they typically report ~ 7400-7500 factors each day.

Oddly, it appears that TJAOI does NOT report "no factor by TF" results. Or at least they haven't reported any of those since March 2015, and even then it was for smaller exponents (< 1M) in the 61-62 bit range.

Unfortunately what that means is that we don't have a record of just how much factoring was done on all of the exponents where no factor was found.

Don't get me wrong, I appreciate the sheer effort involved... this one account has found nearly 120,000 factors by TF just since the start of this year! But if anyone were interested in going a bit or two deeper at some point down the road, how would they know where to pick up?

I'd say nearly all of the factors found recently are in the 60-61 bit range so I'm guessing they're only going up to 2^61, but the exponents being tested are all over the place. From M860143 on Jan 5 to M999958027 on Jan 22.

Maybe George can contact this person (or persons?) and see if they can provide a history of all the factoring they did where no factor was found. It really should be added to the DB.

[QUOTE=ric;424151]It's just a visual annoyance linked to using "smoothed" lines (as opposed to "straight" ones) with hundreds of data points and major variations in data. I've seen it happen in XL, LibreOffice... and now in Google Graphs as well ;-)

In any case, kudos to Aaron: the new charts are awesome.[/QUOTE]

Ah, that would explain it... I forgot it's doing the linear smoothing. If I turn that off it probably bottoms out as expected, but then it's not visually appealing. :smile:

Thanks for the compliments, but really I'm just throwing data at Google Charts and it makes it pretty. If you're saying you like the data itself, I'll accept that. LOL

I like seeing the longer term tflops (with a trendline to boot), and also seeing the daily breakdown of LL and DC results coming in. Fun to note that somewhat recently, daily DC results started approaching parity with first time checks. Might be due to the adjustment George made to the assignment rules a few months back?

Now he can get some visual feedback on how those tweaks are affecting things. Groovy.

[QUOTE=Madpoo;424149]The result that came in had an apparently valid assignment ID and it was assigned to them on 2016-01-06.

There is now an assignment for it that's older and is now a double-check. Kind of weird because it doesn't look like it was actually expired (it's expiration date is missing in the DB), but it does seem like it was old enough (assigned 2015-10-30) that it got reassigned...[/QUOTE]

The Active Assignments page was showing it as being assigned to MikeB, and not proxy2222. Yes, it was showing it assigned 2015-10-30 (to MikeB), and that's not quite 90 days. I believe it will expire around Feb. 10 if no further status update is made.

I'm thinking of running my own DC on this one, as the residue seems suspicious, as I also mentioned.

[QUOTE=srow7;424092]TF does not match
[url]www.mersenne.ca/status/tf/0/1/1/0[/url][/QUOTE]

Hmmm... it occurred to me that I actually don't know what date range you're referring to on mersenne.ca ... your link will show the most recent, but I don't know what dates it was showing when you looked it up. I may have been looking at the wrong date range on the Primenet side. I was looking at all factors reported on 2015-01-24.

In which case, if I understand James' system, that would be this on mersenne.ca:
[URL="http://www.mersenne.ca/status/tf/20160124/20160123/1/0"]http://www.mersenne.ca/status/tf/20160124/20160123/1/0[/URL]

That actually has a smaller # of factors than what Primenet has (988 instead of 1128 from Primenet for that day). Still doesn't match, but I wanted to clear up that I may have been looking at the wrong date info previously.

Now, if I look at Primenet for factors reported yesterday (Jan 25), there are 8686 of them (since I've discovered that TJAOI checks his in on Mon-Fri that makes sense).

So if I look at this mersenne.ca data:
[URL="http://www.mersenne.ca/status/tf/20160125/20160124/1/0"]http://www.mersenne.ca/status/tf/20160125/20160124/1/0[/URL]

It's *really* off.

Again, there could just be a lag in when mersenne.ca slurps the data from Primenet.

[QUOTE=cuBerBruce;424161]The Active Assignments page was showing it as being assigned to MikeB, and not proxy2222. Yes, it was showing it assigned 2015-10-30 (to MikeB), and that's not quite 90 days. I believe it will expire around Feb. 10 if no further status update is made.

I'm thinking of running my own DC on this one, as the residue seems suspicious, as I also mentioned.[/QUOTE]

Might as well go for it if you like. That assignment that's now a DC has little chance of completion.

I've noticed that if an exponent hasn't checked in for a month, there's very little chance it ever will. There are rare exceptions for certain folks (George among them) who may run things offline for months at a time, or maybe in a large install like Curtis where a machine is moved around and plugged in after months in storage, but generally you can spot an abandoned assignment by the fact that it hasn't been seen in 4-5 weeks. :smile: Just don't treat that as a hard and fast rule.

[QUOTE=Madpoo;424180]
I've noticed that if an exponent hasn't checked in for a month, there's very little chance it ever will. There are rare exceptions for certain folks (George among them) who may run things offline for months at a time, or maybe in a large install like Curtis where a machine is moved around and plugged in after months in storage, but generally you can spot an abandoned assignment by the fact that it hasn't been seen in 4-5 weeks. :smile: Just don't treat that as a hard and fast rule.[/QUOTE]

My 4 DC assignments that expired last year were in that category. They continued crunching while the machine was disconnected from the internet, and reported the results as soon as it was reconnected -- of course they were a TC at that point. Oh well.

[QUOTE=Dubslow;424182]My 4 DC assignments that expired last year were in that category.[/QUOTE]

Just to be clear (and this is meant to be friendly and playful)...

Did you not enter a contract for timely completion of the low candidates you were given?

[QUOTE=Madpoo;424179]...

So if I look at this mersenne.ca data:
[URL="http://www.mersenne.ca/status/tf/20160125/20160124/1/0"]http://www.mersenne.ca/status/tf/20160125/20160124/1/0[/URL]

It's *really* off.

Again, there could just be a lag in when mersenne.ca slurps the data from Primenet.[/QUOTE]

The factors of TJAOI are (almost) all for candidates with already known factors, so the report should be alright, since it only puts previously unfactored candidates in that list.

[QUOTE=chalsall;424185]Just to be clear (and this is meant to be friendly and playful)...

Did you not enter a contract for timely completion of the low candidates you were given?[/QUOTE]

No I understand. :smile: Just pointing out one of the exceptions to the rule of thumb.

[QUOTE=Dubslow;424192]No I understand. :smile: Just pointing out one of the exceptions to the rule of thumb.[/QUOTE]

Except in your case it sounds like they went more than a month without contact. :smile: (more like 60 days if they were cat 1 double-checks that expired?)

Still, I know what you meant: that no-contact for a month doesn't necessarily mean the machine/user gave up.

I could narrow it down a bit more and add that if they haven't been in touch for a month *and* they haven't checked in at all since the work was assigned, it's even more likely that it was a "walk away" assignment. Add on to that if it was assigned to "anonymous" it's even more likely.

I mean, no hard feelings, it happens, and it's nice that someone at least gave Prime95 a try. :)

[QUOTE=Madpoo;424202]Except in your case it sounds like they went more than a month without contact. :smile: (more like 60 days if they were cat 1 double-checks that expired?)
[/QUOTE]

Well my usual turn around time is 10-15 days, so the period without contact must have been at least 45-50 days.

[QUOTE=Madpoo;424153]I'd say nearly all of the factors found recently are in the 60-61 bit range so I'm guessing they're only going up to 2^61, but the exponents being tested are all over the place. From M860143 on Jan 5 to M999958027 on Jan 22.

Maybe George can contact this person (or persons?) and see if they can provide a history of all the factoring they did where no factor was found. It really should be added to the DB.[/QUOTE]

They go "by k", and not "by p" as we do our TF. When they are starting reporting 61 bits factors, you can be sure there is no factor left under 61 bits, for all the range. This was discussed here many times. Accidentally, my very first post on this forum, when I joined years ago, described a (not very efficient) method to do so. You can try something like that in Pari to get the idea what they are doing (but with their own faster tools):
[CODE]
/* trial factoring by k, specify a starting point and the outfput file */
ratf(q=2,fis="mf_by_k.out")=
{
while(1,
until(q%8==1 || q%8==7,q=nextprime(q+1)); /*not efficient*/
c=factorint(q-1)[,1]~; /*not efficient*/
for(i=1,#c,
if(c[i]<1000000000 && Mod(2,q)^c[i]==1, print(q" divides M"c[i]); write(fis,q","c[i]))
)
);
}
[/CODE]You can try call it with "ratf(100)" or "ratf(2^36)" or "ratf(2^40)" to see the speed. You can try with a random start like 2^85+rnd(2^84) and you may be lucky to step on a factor of some mersenne numbers (your luck would have to be higher than finding a bitcoin block - valued $11000 at the current price - from the first hash that you try, i.e. in the first millisecond when you start mining, hehe) - that is why it was called "[B][U]ra[/U][/B]tf"


They (TJAOI) are pretty close to their limit, in spite of the much faster tools they have.

Edit: the real question her is: Are they sending in any [U]missed[/U] factors? (i.e. factors for exponents where no factor was known?) Otherwise they are only filling the gaps, but not helping the project at all.

TJAIO has sent in factors that should have been found by TF. We found one user with a lot of bad TF shown by TJAIO's factors and found many more factors that were missed when reprocessing that user's work.

[QUOTE=LaurV;424253]Edit: the real question her is: Are they sending in any [U]missed[/U] factors? (i.e. factors for exponents where no factor was known?) Otherwise they are only filling the gaps, but not helping the project at all.[/QUOTE]Not everyone defines "the project" the same way. If one's "project" is to record all prime divisors (for whatever reason) then TJAIO is doing just fine, and is doing more for the "project" than those silly wasteful LL/DC testers. :razz:

User fireredd finished his/her expired assignment for [url=http://www.mersenne.org/report_exponent/?exp_lo=34969871&exp_hi=&full=1]M34969871[/url], so that one is now successfully triple-checked.

This leads me to believe fireredd will likely complete a similar expired assignment on [url=http://www.mersenne.org/report_exponent/?exp_lo=34973683&exp_hi=&full=1]M34973683[/url] within the next 24 hours. If so, this will then leave only [url=http://www.mersenne.org/report_exponent/?exp_lo=34980299&exp_hi=&full=1]M34980299[/url] remaining for the sub-35M DC milestone.

[QUOTE=LaurV;424253]...
Edit: the real question her is: Are they sending in any [U]missed[/U] factors? (i.e. factors for exponents where no factor was known?) Otherwise they are only filling the gaps, but not helping the project at all.[/QUOTE]

I was wondering that myself, and whether the factoring graphs would be more useful to show only newly factored exponents rather than just any old factor for any exponent, previously factored or not.

That way we'd have a better sense of how the candidates for LL tests are being chipped away by TF.

Maybe I can work that data in there...

Countdown to double-checking all exponents below 35M: [color=red][size=5][b]1[/b][/size][/color]

User fireredd finished his/her expired assignment for M34973683, as I predicted.

We now wait for Greg.

[QUOTE=Madpoo;424308]I was wondering that myself, and whether the factoring graphs would be more useful to show only newly factored exponents rather than just any old factor for any exponent, previously factored or not.

That way we'd have a better sense of how the candidates for LL tests are being chipped away by TF.

Maybe I can work that data in there...[/QUOTE]

I added a new graph... "Newly factored exponents"

Basically I had to do the query per day and join on itself, looking to see if any earlier factors were reported for that same exponent. So it [I]should[/I] be accurate, and it does have a basic average over time which is kind of what I was expecting (for some reason... don't know why I thought it would, but it does).

Again, I included a trend line which I think is nice to see if we're going faster/slower over time.

[QUOTE=cuBerBruce;424348]Countdown to double-checking all exponents below 35M: [color=red][size=5][b]1[/b][/size][/color]

User fireredd finished his/her expired assignment for M34973683, as I predicted.

We now wait for Greg.[/QUOTE]

Cool...

FYI, it'll probably be a while before I add a milestone for DC under 37M, but there is the countdown to proving "M(37156667) is the 45th Mersenne Prime" which is close enough until we actually get closer. Still 15,245 to go on that one... c'mon double checkers! :smile:

[QUOTE]
I added a new graph... "Newly factored exponents"
[/QUOTE]
looks good. thanks

can you double check the new accounts graph
the cpus added is consistantly 10x the users ???
My guess would be a new user adds 1 box at a time.

[QUOTE=srow7;424381]looks good. thanks

can you double check the new accounts graph
the cpus added is consistantly 10x the users ???
My guess would be a new user adds 1 box at a time.[/QUOTE]

Yeah, it seems weird to me to, but the data is what the data is.

I can't explain it... it'd require some digging to figure out why that is.

--- Oh, I just did a cursory look at the # of new CPUs created per user since the start of the month... makes sense now...

Anonymous users don't get a new user ID, but they [B]do[/B] get a new CPU ID. So the new CPU count will always be higher as long as people are just running the app anonymously. Apparently by an order of magnitude... oh well.

64M and under - soon to expire assignments
 

There are 5 exponents that are soon to expire (4 of which seem like they already should have?)

I did the thing I did for the < 35M stuff and created my own assignments manually to make sure when they do expire, they won't get sucked up by someone who'll sit on them for another 3 months before expiring again...

The exponents in question are:
61552507 (will expire on Feb 2)

These 4 were all assigned last September and I have no idea why they weren't expired already... they're 122 to 131 days old, well past the "finish in 90 days" threshold:
63362797
63479179
63784823
63823523

Those last 4, I went ahead and started testing them since they really should have expired anyway. The 61M, I'll wait until it actually expires before doing a test.

As we go, I think this is a safe way to make sure exponents like these are handled and not reassigned to another slowpoke. I'm not saying *I* have to be the one to test them, but it'll reserve them in case we get another volunteer who will get it done promptly.

Meanwhile, I do kind of like the idea of a "cat 0" where people are actually lumped into that category by a server admin based on their track record of not flaking off, unlike the current "cat 1" system which is opt-in and apparently people are getting assignments they shouldn't.

I don't know what would be involved in a system like that because the assignment rules as they are now are already pretty complex, but I think it would help out when these "smallest 100" exponents in either DC or LL get reassigned, and we can be confident the next person will actually get them done.

[QUOTE=Madpoo;424421]These 4 were all assigned last September and I have no idea why they weren't expired already... they're 122 to 131 days old, well past the "finish in 90 days" threshold:[/QUOTE]

Looking at [URL="http://www.mersenne.org/assignments/?exp_lo=60000000&exp_hi=65000000&execm=1&exdchk=1&exp1=1&extf=1"]this report[/URL] there are many candidates which should have already been recycled.

[QUOTE=Madpoo;424421]
Meanwhile, I do kind of like the idea of a "cat 0" where people are actually lumped into that category by a server admin based on their track record of not flaking off, unlike the current "cat 1" system which is opt-in and apparently people are getting assignments they shouldn't.

I don't know what would be involved in a system like that because the assignment rules as they are now are already pretty complex, but I think it would help out when these "smallest 100" exponents in either DC or LL get reassigned, and we can be confident the next person will actually get them done.[/QUOTE]

[QUOTE=Dubslow;423956]
I think there should be a fifth category, called Cat 0 for backwards compatibility, with the following entry and completion criteria (differences from Cat 1 bolded):

[code]
First [B]50[/B] assignments

Exponents below [B]35171537[/B]

Assigned to users that promise to complete assignments quickly. Computer must be proven reliable,
returned at least [STRIKE]4[/STRIKE] [B]6[/B] results in the last 90 days for each LL worker thread, and
"days of work to queue" <= [B]2[/B]

Must be completed in [B]30[/B] days

Assignments are recycled when assignment is more than [B]30[/B] days old.
[/code]
The 30 day period to completion is quite generous, to help minimize duplicate work that happens in Cat 1 and would happen here too, but I think the [STRIKE]4[/STRIKE] 6 results in the last 90 days would still sufficiently guarantee a speedy return well within 15 days, even if there are 30 before the assignment is recycled.
[/QUOTE]

I should correct my post: I meant either 6 results in the last 90 days, or 4 in the last 60 -- either way, something that amounts to a 15 day average turn around in the last 60 or 90 days. The current Cat 1-4 requirement is an average 45 day turnaround, so I think this Cat 0 requirement would be substantially more difficult to meet, and so substantially less computers than even Cat 1 would be eligible -- and further, the time between when a computer stops doing useful work and when it becomes ineligible for Cat 0 is also very much reduced, so only truly active computers would be eligible. It wouldn't increase rule complexity either, just have way more stringent values.

[QUOTE=Dubslow;424424]I should correct my post: I meant either 6 results in the last 90 days, or 4 in the last 60 -- either way, something that amounts to a 15 day average turn around in the last 60 or 90 days. The current Cat 1-4 requirement is an average 45 day turnaround, so I think this Cat 0 requirement would be substantially more difficult to meet, and so substantially less computers than even Cat 1 would be eligible -- and further, the time between when a computer stops doing useful work and when it becomes ineligible for Cat 0 is also very much reduced, so only truly active computers would be eligible. It wouldn't increase rule complexity either, just have way more stringent values.[/QUOTE]

Why not simply adjust Cat 1 and Cat 2? I remember reading somewhere that there aren't many Cat 3 machines, so it would be okay to put more machines in that category.

[QUOTE=Madpoo;423839]...
It does remind me that I should get with George and discuss looking at the track record of CPUs that have the option ticked to get priority assignments. If they have that box checked but have done a lousy job of turning in assignments in a timely fashion, I vote to uncheck that box for them.

In other words, it's kind of lame when a cat 1 assignment goes out to someone who regularly takes 3+ months to finish, or has a lot of expired stuff in their past.
...[/QUOTE]

I did a cursory look.

18 users have had 2+ expired assignments (LL and DC only, not counting expired factoring stuff) just in the last 30 days, but they've checked the box to get preferred assignments.

Of those 18, 3 users currently have at least one Cat 1 assignment in either the LL or DC ranges.

If I broaden it to 2+ expired assignments in the past *60* days, there are 30 users, 4 with a cat 1 assignment.

Well, this one is *almost* cat 1... it was assigned back in April 2014 (not grandfathered) so I have no idea why it's not expired already... at least we can say that it wasn't cat 1 (or even cat 3) when it was assigned nearly 2 years ago.
[URL="http://www.mersenne.org/M67729117"]M67729117[/URL]

Still, the user has had 7 expired assignments in the past 2 months which I think means they shouldn't be getting preferred assignments if they're letting other stuff expire.

Here's another example:
[URL="http://www.mersenne.org/M36542903"]M36542903[/URL]

It was probably cat 2 when assigned, but even then, a user with 10 expired assignments in the last 2 months shouldn't be getting preferred stuff, even cat 2.

One more example:
[URL="http://www.mersenne.org/M35049253"]M35049253[/URL]

Pretty sure this would have been cat 1 when assigned... user has 8 expired assignments in the last 60 days.

At least in that case it seems like the user is working on it... it's a DC that's 96 days old and I thought it would have expired after 60, so there must be some grace period in there if the user has reported progress, or updated recently?

Even if we believe its self-reported ETA of Jan 28 (today), I don't consider 96 days to be a fulfillment of "Assigned to users that promise to complete assignments quickly."

Emphasis on "quickly". 96 days to finish something in the 35M range... that's not quick. :smile:

[QUOTE=Mark Rose;424426]Why not simply adjust Cat 1 and Cat 2? I remember reading somewhere that there aren't many Cat 3 machines, so it would be okay to put more machines in that category.[/QUOTE]

Yes, that would be entirely viable as well. I've always thought in the back of my mind that the 4 categories seem a bit too many.

The main thrust of the idea is substantially increasing the number of recent results, from the average 45 day turn around to 15. Checking for no expired assignments for the most stringent category wouldn't be a bad idea, though it might count as increasing the rule complexity.

[QUOTE=Madpoo;424421]These 4 were all assigned last September and I have no idea why they weren't expired already... they're 122 to 131 days old, well past the "finish in 90 days" threshold:
63362797
63479179
63784823
63823523[/QUOTE]

I believe these were cat 2 when assigned. That means they will expire at 150 days since they have moved into the cat 1 range.

[QUOTE=Mark Rose;424426]Why not simply adjust Cat 1 and Cat 2? I remember reading somewhere that there aren't many Cat 3 machines, so it would be okay to put more machines in that category.[/QUOTE]

Cat 3 is already the most served.

Cat 1 and 2 require a promise from the user to complete quickly.

Please see [URL="http://www.mersenne.org/thresholds/"]this link[/URL] for details.

[QUOTE=chalsall;424432]Cat 3 is already the most served.

Cat 1 and 2 require a promise from the user to complete quickly.

Please see [URL="http://www.mersenne.org/thresholds/"]this link[/URL] for details.[/QUOTE]

As far as I can tell, Cat 3 also requires that promise.

[QUOTE=Dubslow;424433]As far as I can tell, Cat 3 also requires that promise.[/QUOTE]

Nope. Please read the language carefully.

The promise is only required for those requesting manual assignments. Otherwise they will get Cat 4.

[QUOTE=chalsall;424435]Nope. Please read the language carefully.

The promise is only required for those requesting manual assignments. Otherwise they will get Cat 4.[/QUOTE]

Ahh, I see, yet another case in which I had parentheses to help me figure out which clauses go with which conjunctions.

[QUOTE=chalsall;424423]Looking at [URL="http://www.mersenne.org/assignments/?exp_lo=60000000&exp_hi=65000000&execm=1&exdchk=1&exp1=1&extf=1"]this report[/URL] there are many candidates which should have already been recycled.[/QUOTE]

I didn't see any problems here. You need to look at the category threshold at the time the exponent was assigned. For example, the oldest from that list:

[CODE]63362797 LL LL, 78.80% 132 -3 2015-09-19 2015-12-01 2015-12-02 2016-01-26 Mark Hoeting[/CODE]

was a cat 2 assignment. See [url]http://www.mersenne.org/thresholds/?dt=2015-09-19[/url]


Now does the fact that cat 2 assignments are becoming "cat 0" assignments within 150 days mean that we should adjust the definition of cat 1 or cat 2??? May well be. Perhaps we should change cat 1 to first 5000 LL tests. Comments?

[QUOTE=Madpoo;424421]Those last 4, I went ahead and started testing them since they really should have expired anyway. The 61M, I'll wait until it actually expires before doing a test.

As we go, I think this is a safe way to make sure exponents like these are handled and not reassigned to another slowpoke. I'm not saying *I* have to be the one to test them, but it'll reserve them in case we get another volunteer who will get it done promptly.[/QUOTE]

No they should not have expired.

I'm somewhat distressed. The whole point of the "Cat 1/2/3/4" overhaul was to eliminate or at least greatly reduce poaching because milestones would be making steady progress. Instead, it seems to have made people even more impatient.

Let's tweak the "cat" system, rather than embark on more poaching. To that end, I'm studying the cat 0 suggestions and using the number of recently expired assignments to improve our assignment strategy.

[QUOTE=Prime95;424448]I didn't see any problems here. You need to look at the category threshold at the time the exponent was assigned. For example, the oldest from that list:

[CODE]63362797 LL LL, 78.80% 132 -3 2015-09-19 2015-12-01 2015-12-02 2016-01-26 Mark Hoeting[/CODE]

was a cat 2 assignment. See [url]http://www.mersenne.org/thresholds/?dt=2015-09-19[/url]


Now does the fact that cat 2 assignments are becoming "cat 0" assignments within 150 days mean that we should adjust the definition of cat 1 or cat 2??? May well be. Perhaps we should change cat 1 to first 5000 LL tests. Comments?[/QUOTE]

[QUOTE=Prime95;424449]No they should not have expired.

I'm somewhat distressed. The whole point of the "Cat 1/2/3/4" overhaul was to eliminate or at least greatly reduce poaching because milestones would be making steady progress. Instead, it seems to have made people even more impatient.

Let's tweak the "cat" system, rather than embark on more poaching. To that end, I'm studying the cat 0 suggestions and using the number of recently expired assignments to improve our assignment strategy.[/QUOTE]

I agree that some tweaking is in order, and your statements seem to be the right approach.

I will comment that, generally speaking, predicting when previously-solid contributors will go offline is next to impossible. The best we can do is tighten up our definitions of "solid contributors" -- either directly modifying the current criteria, or as madpoo suggested, we could perhaps see if they have any recent assignment expirations. Ideally the criterion for "solid" is one such that when a system goes bad, it ceases to be eligible as quickly as possible.

I think the "x results in the last y days" is the best criterion to tighten up in the various categories.

It certainly seems that adjusting the size of the categories is also in order, for the reasons you state. A few too many assignments from each category are moving down one or two categories before the original assignment time is up. It may be worth setting the deadlines for each category based on how long it takes the size of the next smaller categories to completely change. That is, if the first 10,000 (or however many) assignments in Cat 2 takes 6 months to clear through at current GIMPS pace, then the Cat 3 deadline should be no more than 6 months (or the Cat 2 size should be increased, one or the other). madpoo is of course best able to acquire the various data needed for this particular kind of decision.

[QUOTE=Madpoo;424428]
One more example:
[URL="http://www.mersenne.org/M35049253"]M35049253[/URL]

Pretty sure this would have been cat 1 when assigned... user has 8 expired assignments in the last 60 days.[/QUOTE]

I looked at this one. It was borderline cat 1 / cat 2 at time of assignment -- not sure which it is. The user now has 8 expired assignments, but they happened after the initial assignment.

[QUOTE=Madpoo;424428]
Here's another example:
[URL="http://www.mersenne.org/M36542903"]M36542903[/URL]

It was probably cat 2 when assigned, but even then, a user with 10 expired assignments in the last 2 months shouldn't be getting preferred stuff, even cat 2.

[/QUOTE]

This one had 7 expired assignments in the previous 11 months at the time of assignment.

[QUOTE=Madpoo;424428]

Well, this one is *almost* cat 1... it was assigned back in April 2014 (not grandfathered) so I have no idea why it's not expired already... at least we can say that it wasn't cat 1 (or even cat 3) when it was assigned nearly 2 years ago.
[URL="http://www.mersenne.org/M67729117"]M67729117[/URL][/QUOTE]

Grandfathered assignments are given an infinite amount of time as long as both
a) They report in at least every 60 days
b) The exponent does not become cat 1.

This exponent will fail soon on condition (b).

[QUOTE=Mark Rose;424426]Why not simply adjust Cat 1 and Cat 2?[/QUOTE]

On 3/1/14:
Cat 1 started with first 5000, Cat 2 first 15000.

On 3/2/15, based on a year of data and discussed somewhere in this forum:
Cat changed to 3000, Cat 2 dropped to first 10000.

Today we are not happy with slower cat 2 assignments dropping well down into the cat 1 area before the 150 day rule expires them. So, I guess we dropped the cat 1 number too much. I'll adjust upward to 4000.

[QUOTE=Prime95;424458] So, I guess we dropped the cat 1 number too much. I'll adjust upward to 4000.[/QUOTE]
:tu:
We don't need more cats. Enforce the one we have. The system is working well. It may look "slow" looked at from the perspective of Aaron and Chris :razz: but we don't all have billions of cores, dogs to whet against one DC, so 10-20 days for us for a DC (including the queue in front of it) is quite ok.

Perhaps it is time to record the actual Category rule applied for an assignment (instead of doing a forensic reconstruction of what would have been the category)?

[QUOTE=Madpoo;424428]

Well, this one is *almost* cat 1... it was assigned back in April 2014 (not grandfathered) so I have no idea why it's not expired already... at least we can say that it wasn't cat 1 (or even cat 3) when it was assigned nearly 2 years ago.
[URL="http://www.mersenne.org/M67729117"]M67729117[/URL][/QUOTE]

Correction. This was not a grandfathered assignment. It was cat 4 at time of assignment.

However, like grandfathered assignments it will not expire until it becomes cat 1.

This will happen real soon now as I just updated cat 1 to the first 4000 exponents.

I don't see the change reflected on the thresholds page... perhaps the 3000 figure there needs to be adjusted separately?

[QUOTE=Prime95;424449]No they should not have expired.

I'm somewhat distressed. The whole point of the "Cat 1/2/3/4" overhaul was to eliminate or at least greatly reduce poaching because milestones would be making steady progress. Instead, it seems to have made people even more impatient.

Let's tweak the "cat" system, rather than embark on more poaching. To that end, I'm studying the cat 0 suggestions and using the number of recently expired assignments to improve our assignment strategy.[/QUOTE]

Mea culpa... I missed the clause where a cat 2 that moves into cat 1 doesn't inherit the native cat 1 expiration date.

[QUOTE=LaurV;424465]:tu:
We don't need more cats. Enforce the one we have. The system is working well. It may look "slow" looked at from the perspective of Aaron and Chris :razz: but we don't all have billions of cores, dogs to whet against one DC, so 10-20 days for us for a DC (including the queue in front of it) is quite ok.[/QUOTE]

Good points. Fortunately the cat 1 stuff also requires having less than 10 days in the work queue, to avoid that problem of getting a cat 1 and having it sit behind a couple weeks of other work before even starting. :smile:

[QUOTE=Mark Rose;424483]I don't see the change reflected on the thresholds page... perhaps the 3000 figure there needs to be adjusted separately?[/QUOTE]

It might not kick in until the next nightly job that changes the thresholds...

Let's say we tried an unofficial DC cat 0 that required a queue depth under 3 days and say 6 LL results per worker in the last 90 days. In other words, serious machines.

Would that really solve the angst exhibited by folks here? When they look at the lowest 100 assignments they will still see it littered with cat 1 assignments waiting for the 90 days to expire. Several will look obviously abandoned as the computer is 10-30 days overdue on a check in -- people will grumble. They will see dozens of exponents where the computer is highly-unlikely / unlikely / possibly-will / should-but-will-be-close chance to get to 100% before the deadline -- people will grumble.

Yes, once the 90-day expiration hits they know that it will be completed by the serious machines in just 10-15 days. But if we start the test without waiting for the 90 day expiration we won't even need to wait those 10-15 days......more grumbling.

The "Cat project" goal was to have steady progression on milestones and reduced incentive for poaching. In my opinion it is a success on the first goal and a failure in the second.

Thoughts? Should we go ahead with cat 0 anyway?

[QUOTE=axn;424474]Perhaps it is time to record the actual Category rule applied for an assignment (instead of doing a forensic reconstruction of what would have been the category)?[/QUOTE]

There is a SQL view that has that info. It shouldn't be hard to add it to the active assignments report.

What about making regular check-ins a requirement to keep an exponent that enters Cat 1? So any exponent in the Cat 1 range that hasn't checked in for a week gets expired.

People who disconnect their machines should probably be working on larger exponents.

I think one reason why a good number of assignments are not being completed on time is a lack of information given in a user's assignments page.

That page:
- gives no indication if an assignment has moved into the first category.
- gives no indication of what category an assignment has (the cat it was in when assigned)
- gives no indication of when it is expected to expire based upon current status

Of course it is possible for a user to figure these things out, but it can be awkward to do so. The page that shows category boundaries for a given date is not even accessible from the menus or have any other GUI support (as far as I know).

I think at a minimum, the assignments page should show the category of each assignment. If it's too time-consuming for the server to provide such information, then I would agree with axn's suggestion to record the cat value in the database directly. (There might be some issues with this if, for example, an assignment is poached. It may need to change from cat 1 LL to cat 4 DC, for instance, I think.)

[QUOTE=Prime95;424500]There is a SQL view that has that info. It shouldn't be hard to add it to the active assignments report.[/QUOTE]

Unless the fact is recorded at the time of assignment creation, this will not help.

I am not necessarily advocating that this information be made public (though that could be helpful as well). I am essentially proposing a design whereby Aaron or yourself can accurately figure the actual expiration policy applicable for any given assignment (instead of guessing/back calculating).

If the information is available, but Aaron merely overlooked it, then I misunderstood the situation.

[QUOTE=Prime95;424499]Let's say we tried an unofficial DC cat 0 that required a queue depth under 3 days and say 6 LL results per worker in the last 90 days. In other words, serious machines.

Would that really solve the angst exhibited by folks here? When they look at the lowest 100 assignments they will still see it littered with cat 1 assignments waiting for the 90 days to expire. Several will look obviously abandoned as the computer is 10-30 days overdue on a check in -- people will grumble. They will see dozens of exponents where the computer is highly-unlikely / unlikely / possibly-will / should-but-will-be-close chance to get to 100% before the deadline -- people will grumble.

Yes, once the 90-day expiration hits they know that it will be completed by the serious machines in just 10-15 days. But if we start the test without waiting for the 90 day expiration we won't even need to wait those 10-15 days......more grumbling.

The "Cat project" goal was to have steady progression on milestones and reduced incentive for poaching. In my opinion it is a success on the first goal and a failure in the second.

Thoughts? Should we go ahead with cat 0 anyway?[/QUOTE]

I think it's a success on the first and largely a success on the second. Despite all the grumbling we're doing, I'm pretty certain that poaching is at least an order of magnitude less than it was 3 years ago, not to mention far more cautious to boot (meaning most recent poachings have been proven "justified" after the fact).

[quote]Yes, once the 90-day expiration hits they know that it will be completed by the serious machines in just 10-15 days. But if we start the test without waiting for the 90 day expiration we won't even need to wait those 10-15 days......more grumbling.[/quote]
I disagree about this last grumbling. If the hypothetical Cat 0 was sufficiently stringent, I believe most poachers would realize that they would, at best, be competing with the Cat 0s, rather than the Cat 1s as currently (or worse, as previously). In fact, I bet nearly all poachers would be qualified for Cat 0 -- so in a sense, it would provide the exponents most likely to be poached to those most likely to poach them.

Basically, poaching has been nearly wiped out, and I do believe that a far more stringent last category (whether it be 0 or a retooling of the existing 1-4) would get the job done, more or less. (Say if 90% of poaching from three years ago is now gone, then I expect that Cat 0 would be another figurative 90% of what's left.) At any rate, a new Cat 0 certainly wouldn't hurt.

And the more I think about it, the more I concur with madpoo that limiting the number of recent expiries is also a good thing, say Cat 0 has 4 tests in 60 days and no expiries in the last 60, and maybe Cat 1 or 2 could have a maximum number of recent expiries as well.

[QUOTE=Prime95;424499]...
Thoughts? Should we go ahead with cat 0 anyway?[/QUOTE]If a category 0 is created, how will a user or a CPU qualify ? Couldn't we use the response to that question as an indication on how to adjust the current system ?

In my opinion :

- cat 1 or cat 2 assignments should be checked for regular progress, say at least once a week, there could be different thresholds for cat 1 and cat 2.

- the preferred assignments setting should be by CPU and not by user, another way of achieving this would be to have more stringent rules for computing the reliability of a CPU.

- cat 3 and cat 4 recycling rules should be more stringent. For Cat 3 I would propose removing the possibility of manual extension and recycling when the exponent moves in cat 2 : "Assignments are recycled if they are not started within 180 days or when the exponent moves into the second or first category and the assignment is more than 240 days old." If the number of cat 2 exponents is big enough (about a year of work in double checking and first time testing respectively) cat 3 and cat 4 assignments should not become cat 1 assignments.

I think that multiplying categories will not solve the problems.

Jacob

[QUOTE=S485122;424523]I think that multiplying categories will not solve the problems[/QUOTE]
:tu: I think Aaron has things under control.

A thing I forgot : whatever the system used, there will always be a moment when only a few assignments remain to attain a milestone, some people just cannot stand this state of affairs lasting for more than a few hours...

It is true that the trailing edge for first time assignments takes longer to to resorb than that for the second time checks. But in a few month this should be done.

Jacob

[QUOTE=S485122;424544]...some people just cannot stand this state of affairs lasting for more than a few hours...[/QUOTE]

I think this is more likely a "race condition" between the original assignee (which got recycled) and the new assignee, rather than an unassigned "poaching".

Looking at the cat 1 first time tests there are 48 assignments older than 90 days that have not been recycled. 31 assignments have not been updated in the last 30 days.

Looking at exponents assigned for double checks in the same range, some exponents are clearly lost by their owner but have not been recycled : 60589631 and 60971909 are obvious examples. Then 115 have not been updated in 180 days.

I would propose the following recycling rule for cat 4 :
"Assignments are recycled if
- they are not started within 180 days
- they are not manually extended or updated for 180 days
- they are more than 360 days old and the exponent has moved in cat 2 or cat 1."

Jacob

Countdown to double-checking all exponents below 35M: [color=red][size=7][b]0[/b][/size][/color]

:party: :party: :party:

A poacher using user name proxy2222 just couldn't seem to wait one more day for Greg to finish the assignment. (Well, I suppose it wasn't exactly smart for Greg to not start that assignment for about six days, either.)

[QUOTE=S485122;424523]In my opinion :

- cat 1 or cat 2 assignments should be checked for regular progress, say at least once a week, there could be different thresholds for cat 1 and cat 2.

- the preferred assignments setting should be by CPU and not by user, another way of achieving this would be to have more stringent rules for computing the reliability of a CPU.[/QUOTE]

I agree. And further I would argue that the new assignment rules have generally worked out really well. It has made us look a lot more organized; when M48 was found the assignments were all over the map!

I find it interesting that the recycling rules have worked _really_ well for the low DC'ing range. The low LL'ing range seems to be a bit more problematic. I suspect this is because most people want to become famous by finding a very large prime number, without really realizing just how much commitment is involved.

I would like to support the idea that regular check-ins are an additional requirement for Cat 1 and Cat 2 assignments. Most check in once a day, so perhaps a clause such as "Assignment is recycled if not checked in for seven (7) days". Currently it takes sixty days without a check-in before a candidate is recycled (in all categories).

At the end of the day, we're not going to be able to eliminate "toes being stepped on" if assignments are recycled. The best we can do is try to set things up such that such cases are minimized. It is very difficult (impossible?) to perfectly manage disparate independent "actors".

Lastly, a personal bug-a-boo of mine... I find it a bit ridiculous that even anonymous users can come in and get unlimited numbers of assignments via the Manual Assignment page which are almost never worked, but take 180 days to expire. This has caused (and is causing) headaches trying to appropriately feed the P-1'ers.

[QUOTE=axn;424508]Unless the fact is recorded at the time of assignment creation, this will not help.

I am not necessarily advocating that this information be made public (though that could be helpful as well). I am essentially proposing a design whereby Aaron or yourself can accurately figure the actual expiration policy applicable for any given assignment (instead of guessing/back calculating).

If the information is available, but Aaron merely overlooked it, then I misunderstood the situation.[/QUOTE]

That's basically the case. Well, I knew there was a table in the database that records the threshold/category data going all the way back to Feb 2014 when the new assignment rules first kicked in, so using that data and the date an assignment was created it's possible to figure out what category it was in when assigned. And you're correct, that info is not publicly available anywhere, although I think there may be people who save that info from the /thresholds/ page for later reference.

Anyway, my mistake was not understanding that when an exponent moves from one category to a lower one, it didn't have to follow the rules of it's current category, but rather it would keep the expiration rule according to the category it was in when assigned.

Maybe now that I understand that, I can see if there's a way to include some kind of 'expiration date' in the assignment report which would clarify things.

[QUOTE=S485122;424544]A thing I forgot : whatever the system used, there will always be a moment when only a few assignments remain to attain a milestone, some people just cannot stand this state of affairs lasting for more than a few hours...

It is true that the trailing edge for first time assignments takes longer to to resorb than that for the second time checks. But in a few month this should be done.
[/QUOTE]

I'm probably as guilty of that as anyone. That said, I'm happy to let things work their natural course as long as it looks like any remaining assignments are on track to finish in due course.

Where I (and others) get antsy (and perhaps I need to take a chill pill) is when it's obvious there's an assignment or two that simply aren't being done. If they're expiring soon that's fine, but where the trouble comes in is that there are simply people out there who opt to get preferred assignments who really shouldn't be.

That means that when these few remaining exponents expire, they may be picked up by one of them... so it stands a fair chance of taking another 60 / 90 days of sitting and wondering and baiting the poachers. :smile:

Odds are the work would be reassigned to someone who completes it quickly, but it's not certain, and I think it should be a bit more certain that it'll go to someone who really truly means it when they say they'll complete the work in a timely fashion.

To me that means weeding out the folks who tick that box but let exponents expire anyway. That *should* be part of the criteria in getting these cat 1 (or even cat 2) assignments... people with a proven track record (over the course of the past few months) of not letting things slip.

And if it only looks at the past couple months, then people can rehabilitate their trustworthiness to get preferred work by simply doing the work assigned to them without letting them dry on the vine for a couple months.

I don't even know that the idea of a "category 0" is needed as long as we'd be reasonably certain that whoever picked up the work next would actually follow through. I'd be happy, at any rate.

[QUOTE=cuBerBruce;424551]Countdown to double-checking all exponents below 35M: [color=red][size=7][b]0[/b][/size][/color][/QUOTE]

Milestone page updated.

[QUOTE=chalsall;424564]...Lastly, a personal bug-a-boo of mine... I find it a bit ridiculous that even anonymous users can come in and get unlimited numbers of assignments via the Manual Assignment page which are almost never worked, but take 180 days to expire. This has caused (and is causing) headaches trying to appropriately feed the P-1'ers.[/QUOTE]

I think this was also the issue with 100M digit assignments for LL, and the desire among some folks to do additional factoring on them, but couldn't because they were assigned many (many!) years ago.

For cat 4 work, the general notion was that even if they'd passed their expiration date, as long as they were *still* category 4 there was no rush to expire them.

That's probably a decent idea *as long as* the assignment has been updated recently, giving us some indication that, "yes, it's taking a really long time, but hey, I really am making progress and I'm still alive out here".

In terms of that sort of grace for the larger exponents, I could see a case being made to go ahead and expire them anyway if they updated the assignment in the expiration-time window. Meaning large cat 4 work that is still cat 4 when it should have expired will be made available again if it hasn't even been updated in a year.

The "extended super awesome" grace period might only apply to the grandfathered assignments... so don't quote me on how that works in regards to assignments made after Feb. 2014.

[QUOTE=Madpoo;424586]The "extended super awesome" grace period might only apply to the grandfathered assignments... so don't quote me on how that works in regards to assignments made after Feb. 2014.[/QUOTE]

"Assignments made prior to 2014-03-01 will be given, as promised, at least a year to complete.

Surely grandfathered assignments no longer enter the equation... (And, don't call me Shirley....)

[QUOTE=chalsall;424594]"Assignments made prior to 2014-03-01 will be given, as promised, at least a year to complete.

Surely grandfathered assignments no longer enter the equation... (And, don't call me Shirley....)[/QUOTE]

There are some still. *Most* are in the 100M digit range (332M +)

On the double-checking side of things, the smallest one is M42577387 so it's still far out from the DC wavefront.

Assigned 2010-01-25 and last updated 2015-12-28. But hey, it's at zero percent done and it's supposed to check in again sometime in April. :smile:

That one is well past the expiration date, but since it's cat 4 it's in an extended grace period. It'll expire the moment it becomes cat 3, I suspect.

On the first-time LL side, the smallest one is M67852651. Just *barely* a cat 2 assignment. It'll become cat 1 very soon (threshold is 67605842 right now).

My estimate of M67852651 is 2024-06-18. But it's already past it's maximum expiration date... pretty sure it'll expire the instant it's cat 1.

Similar situation with M67852927 (same user in fact).

There are a total of 13 grandfathered first time checks below 70M. Then the rest of them are 100M and up.

Here's how the rest break down:[LIST][*]38 DC grandfathered assignments (unsurprisingly, a good bit of these were once LL assignments that got switched to DC when someone checked in a first time test).[*]917 LL grandfathered assignments. Just those 13 < 70M and then 904 > 100M. In fact, 747 of them are 332M and up.[/LIST]
Of the LL grandfathered stuff, there are only a couple that I think have a chance of completing before expiring:
M69211411 (60 days to go)
M69211427 (48 days to go)

It depends on when those become cat 1, I guess, since both of those are already 130 days past the grandfathered expiration times, and they're on borrowed time right now.

If this kind of trivia is interesting, the absolute [B]oldest[/B] assignment is:
[URL="http://www.mersenne.org/M332197309"]M332197309[/URL] - December 2008... yes, over 6 years ago. But it *is* still being worked on... 84.6% done and a self-reported ETA of September 2016. My own observed ETA for it is March 2017 based on it's rate of 0.0388% per day of progress.

Some raw data on current assignments:

[CODE]LL cat counts
1 824
2 74
3 7859
4 15681

grandfathered (all manual assignments)
4 13

manual assigns
3 243
4 3543

all extends
3 22
4 173

manuals extended
3 1
4 67

5 days overdue
1 56
2 22
3 1063
4 3558

10 days overdue
1 40
2 10
3 868
4 1693

20 days overdue
1 32
2 10
3 721
4 1214

30 days overdue
1 25
2 10
3 593
4 889

unstarted by cat, month assigned
3 8 2
3 9 13
3 10 11
3 11 37
3 12 41
3 1 139
4 4 14
4 7 1
4 8 291
4 9 301
4 10 472
4 11 442
4 12 403
4 1 1619


DC cat counts
1 549
2 265
3 2162
4 115395

grandfathered
4 29

manual assigns
3 517
4 1342

all extends
3 8
4 103

manuals extends
4 62

5 days overdue
1 39
2 1
3 151
4 76135

10 days overdue
1 22
2 1
3 127
4 54024

20 days overdue
1 2
2 1
3 106
4 31823

30 days overdue
1 2
2 1
3 87
4 16264

unstarted by cat, month assigned
3 8 6
3 10 19
3 11 278
3 12 128
3 1 86
4 3 27
4 4 25
4 5 10
4 6 23
4 7 7
4 8 119
4 9 15
4 10 41
4 11 86
4 12 64
4 1 925

[/CODE]

[QUOTE=cuBerBruce;424161]I'm thinking of running my own DC on this one, as the residue seems suspicious, as I also mentioned.[/QUOTE]

Well, indeed M61233727 has a somewhat interesting 64-bit residue. The residue I got matches that of submitted result (at least all of the non-masked digits match). I will wait for about 11 days when MikeB's assignment will probably expire before submitting my result.

[QUOTE=cuBerBruce;424747]Well, indeed M61233727 has a somewhat interesting 64-bit residue. The residue I got matches that of submitted result (at least all of the non-masked digits match). I will wait for about 11 days when MikeB's assignment will probably expire before submitting my result.[/QUOTE]

Oops! I forgot I needed to remove the result from my results file before connecting to the internet. Oh well, the seemingly abandoned assignment would have expired a few days ago had it not been converted to a DC.

The residue contained a (hex) digit sub-sequence of 6 ascending digits.

M49 DC milestone clock undercounting?
 

It looks like the milestone page countdown to proving that M49 is really M49 might be undercounting the remaining number of tests.

If my understanding of the countdowns is correct, the double-check milestone totals should be equal to the sum of the total number of exponents that have been checked once, and *twice* the total number of virgin (or LL-ERR) exponents. This is because the virgin exponents will each require (at least) *two* tests in order to be successfully double-checked.

AFAICT these countdowns are all correct for the primes for which no virgin tests remain to be cleared (which would include every prime except for M49). But the M49 countdown is only single-counting the virgin tests, and I suspect that if there were other primes (or DC milestones) above the first-LL minimum, their counts might be off as well.

If I have thought this out correctly, the M49 countdown could be fixed by simply adding on the number in the M49 *first-time-test* countdown (e.g. using the present figures, the "big" M49 countdown would become 710,771 + 77,601 = [B]788,372[/B]).

[QUOTE=NBtarheel_33;425767]If my understanding of the countdowns is correct, the double-check milestone totals should be equal to the sum of the total number of exponents that have been checked once, and *twice* the total number of virgin (or LL-ERR) exponents. This is because the virgin exponents will each require (at least) *two* tests in order to be successfully double-checked.[/QUOTE]

It depends on whether you're counting the tests or the exponents. If you're counting the tests, then you can't give any accurate numbers -- I mean, there are going to be some (unpredictable) number of triple checks, quadruple checks, etc... So the only reasonable thing is to give the number of exponents.
/my 2c